Enable AirPrint for any printer

Run AirPrint Activator on your Mac to share local and network attached printers to an iPhone, iPad or iPod Touch running iOS 4.2 or newer. AirPrint Activator listen to all local network printer advertisements and make them available via AirPrint.  If it is shared and visible by your Mac it will be advertised.

Download from here

After updating my OSX boxes to 10.7 there has been some issues with the ARD 3.5.1 Admin/client updates

ssh into the offending machine(s) and type:

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -deactivate -configure -access -off

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -restart -agent -privs -all

sudo chown -R $USER (path/to/dropbox)
sudo chmod -R u+rw (path/to/dropbox)
sudo chown -R $USER ~/.dropbox
sudo chmod -R u+rw ~/.dropbox

Exim as a Smarthost

By adding a smart router you can act as the primary mx for a domain that actually isn’t local to your server at all for example: I used this to push virus & spam filtered mail onto a customers Exchange Server negating the need for POP boxes.

To implement smart routers:

touch /etc/staticroutes

Then open /etc/staticroutes in your favourite text editor (vi is my preference) and add each domain you would like pushed on in the following format (one per line):

domainname.com: target.mail.server

target.mail.server can be a FQDN or an IP address

In the Routers Configuration section of your exim.conf add the following:

static_route:
driver = manualroute
transport = remote_smtp
route_data = ${lookup{$domain}lsearch{/etc/staticroutes}}

Then after an exim restart you should have working smart routers (its always worthwhile to tail the exim_mainlog for a while afterwards just to make sure its ok)

service exim restart

Thanks to Nick Pack

At COMPANY _______ we value your privacy a great deal. Almost as much as we value the ability to take the data you give us and slice, dice, julienne, mash, puree and serve it to our business partners, which may include third-party advertising networks, data brokers, networks of affiliate sites, parent companies, subsidiaries, and other entities, none of which we’ll bother to list here because they can change from week to week and, besides, we know you’re not really paying attention.

We’ll also share all of this information with the government. We’re just suckers for guys with crew cuts carrying subpoenas.

Remember, when you visit our Web site, our Web site is also visiting you. And we’ve brought a dozen or more friends with us, depending on how many ad networks and third-party data services we use. We’re not going to tell which ones, though you could probably figure this out by carefully watching the different URLs that flash across the bottom of your browser as each page loads or when you mouse over various bits. It’s not like you’ve got better things to do.

Each of these sites may leave behind a little gift known as a cookie — a text file filled with inscrutable gibberish that allows various computers around the globe to identify you, including your preferences, browser settings, which parts of the site you visited, which ads you clicked on, and whether you actually purchased something.

Those same cookies may let our advertising and data broker partners track you across every other site you visit, then dump all of your information into a huge database attached to a unique ID number, which they may sell ad infinitum without ever notifying you or asking for permission.

Also: We collect your IP address, which might change every time you log on but probably doesn’t. At the very least, your IP address tells us the name of your ISP and the city where you live; with a legal court order, it can also give us your name and billing address (see guys with crew cuts and subpoenas, above).

Besides your IP, we record some specifics about your operating system and browser. Amazingly, this information (known as your user agent string) can be enough to narrow you down to one of a few hundred people on the Webbernets, all by its lonesome. Isn’t technology wonderful?

The data we collect is strictly anonymous, unless you’ve been kind enough to give us your name, email address, or other identifying information. And even if you have been that kind, we promise we won’t sell that information to anyone else, unless of course our impossibly obtuse privacy policy says otherwise and/or we change our minds tomorrow.

We store this information an indefinite amount of time for reasons even we don’t fully understand. And when we do eventually get around to deleting it, you can bet it’s still kicking around on some network backup drives in somebody’s closet. So once we have it, there’s really no getting it back. Hell, we can’t even find our keys half the time — how do you expect us to keep track of this stuff?

Not to worry, though, because we use the very bestest security measures to protect your data against hackers and identity thieves, though no one has actually ever bothered to verify this. You’ll pretty much just have to take our word for it.

So just to recap: Your information is extremely valuable to us. Our business model would totally collapse without it. No IPO, no stock options; all those 80-hour weeks and bupkis to show for it. So we’ll do our very best to use it in as many potentially profitable ways as we can conjure, over and over, while attempting to convince you there’s nothing to worry about.

(Hey, Did somebody hold a gun to your head and force you to visit this site? No, they did not. Did you run into a pay wall on the home page demanding your Visa number? No, you did not. You think we just give all this stuff away because we’re nice guys?  Bet you also think every roomful of manure has a pony buried inside.)

This privacy policy may change at any time. In fact, it’s changed three times since we first started typing this. Good luck figuring out how, because we’re sure as hell not going to tell you. But then, you probably stopped reading after paragraph three.”

OS X 10.6.5 Letterbox Mail Plugin

Letterbox is a popular plugin for Mail.app that gives you a wide screen three-pane view in Mail, unfortunately the Mac OS X 10.6.5 update broke this plugin. If you don’t mind getting your hands a bit dirty in the Finder, you can fix the plugin to work in 10.6.5 by editing a file. We’ll walk you through it:

Fixing the Letterbox plugin for Mac OS X 10.6.5

  • From the Finder, hit Command+Shift+G and enter ~/Library/Mail/ then hit Go
  • Open Bundles (Disabled) rather than Bundles – note: if you have already opened Mail, the plugin is disabled, if you haven’t opened Mail yet, it will be in Bundles

  • Right-click on Letterbox.mailbundle and select “Show Package Contents”
  • Now open the “Contents” folder inside the Letterbox.mailbundle contents
  • Using a text editor, open Info.plist (you can use TextEdit, don’t use Word)
  • Scroll to the bottom of the Info.plist file and look for “SupportedPluginCompatibilityUUIDs” which is surrounded by key tags, below that will be a bunch of hex strings surrounded by string tags
  • Add the following two strings to the bottom of the list (inside the array tags):
    <string>857A142A-AB81-4D99-BECC-D1B55A86D94E</string>
    <string>BDD81F4D-6881-4A8D-94A7-E67410089EEB</string>

  • Save these changes to the Info.plist file
  • Go back to the Mac OS X desktop and hit Command+Shift+G again, then enter ~/Library/Mail/
  • You’ll see these two folders again: Bundles and Bundles (Disabled), what you need to do is move the Letterbox.mailbundle plugin from the (Disabled) folder to the Bundles folder. Do this just by dragging the file from one folder window to the other.
  • Relaunch Mail.app

Now when you open the Mail app again, your Letterbox plugin will be restored and everything should be working in full widescreen three paneled glory again.

Deduplication, the ability to eliminate redundant files, blocks of data or bytes of data from storage has primarily been applied to backup. In this use case, there’s typically a high level of redundant data due to having multiple copies of files contained in multiple backup cycles, performance impact is often less important, and potential data loss, while a concern, may not be critical due to having multiple copies of files. Deduplication  efficiency, or ‘payoff’, is high because of the amount of natural data redundancy in backups. As deduplication moves upstream to production, also called primary storage, each of these “important” areas becomes critical.

In primary storage the first reality is that the payoff from applying deduplication may not be as great because there’s less redundant data. Another realization is that performance impact must be minimal for the solution to be accepted by IT. Further, even the data loss of a single transaction has to be avoided. In short, the requirements are dramatically higher for deduplication on primary storage than with backup storage. These issues have in fact severely limited the application of deduplication on primarily storage for files and have nearly eliminated the application for block-based data.

Options for Primary Storage Deduplication

A hot topic of debate revolves around when to process data in a system to see if there is redundancy to be optimized. The alternative to real time deduplication is to examine the data during periods of inactivity, when the application servers have excess processing power and I/O is not being consumed by normal read/write tasks. Deduplication would then be done in batch mode as cycles were available. Conventional wisdom holds that this approach is consistent with other IT processes. However, this approach rapidly becomes complex. How, for example, does the system know and track the deduplication status? What happens if the deduplication backlog extends beyond a normal workday? As a result, primary storage deduplication has been more of a dream than an implementable reality.

Real time deduplication, in contrast, processes data in-line before it’s written to disk. This obviously consumes processing and I/O resources from normal read/write operations. Often forgotten though, is that if there’s redundant data, that data no longer has to be written to disk, only a meta-data table needs to be updated. Keep in mind that writing or rewriting data is potentially the ‘heaviest lifting’ that a file system and its underlying storage components have to perform. Not only does the data need to be written, a RAID calculation also needs to be made and one or more (assuming RAID 6) parity bits need to be written. Finally, if there is a snapshot in place the tables holding those parity bits need to be updated. If the data is redundant, something that can be determined prior to it being written, then all of these steps can be avoided. The result can be an actual performance improvement, rather than a loss, in even moderately redundant data sets.

The other advantage of real time data deduplication is in storage management. When deduplication is run after the fact, it requires the storage admin to manage two separate data states (optimized and not optimized) on the same volume. This can significantly add to overall complexity. With real time deduplication, since data is always in its optimized form, there are no calculations required to allocate pre-optimized and optimized datasets.

However, as mentioned previously, each processing cycle of an application server, particularly in virtualized environments, is precious. So, even though real time deduplication provides benefits, the tradeoff in terms of CPU utilization did not appear justified.

Recently (in approximately March 2010), a new real time deduplication scenario has arisen. The new scenario is utilizing an advanced file system, called the Zettabyte Filesystem (ZFS), embedded in the storage subsystem to handle deduplication. ZFS has been embedded into a storage platform called NexentaStorTM from Nexenta Systems, Inc. NexentaStor runs on a dedicated processor card in the storage subsystem. This provides two main advantages: 1) Deduplication can be handled in real time and 2) The application server is actually offloaded by deduplication.

The Advantage of Real Time File System-based Deduplication

With real time deduplication built right into the file system, the two resources impacted are the CPU power of the storage processor card and of the read/write capacity of the storage system, as there is an additional read I/O operation to check the meta-data tables. The CPU resource is needed to create the hash key that helps identify the data segment as being unique or not. This key is then compared to a list of hashes, commonly called a hash table. This look-up causes the additional read I/O. In both cases the open nature of the ZFS and NexentaStor file system helps alleviate the potential challenges.

First, since the ZFS file system runs on practically any hardware, configuring a storage server with additional CPU horsepower and RAM is not nearly as expensive as it is with proprietary systems. Second, because the file system can leverage solid state disk (SSD) natively, the hash table can be stored on flash SSD, which is ideal for high-read environments. These two factors quickly negate any performance impact that a user may experience. Finally, specific to ZFS, the file system is already examining data segments as part of its internal efforts to eliminate silent data corruption. The file system, when deduplication is enabled, is simply extending its analysis of those segments.

Beyond deduplication it’s important that the optimization also include the ability to compress data. As stated earlier, deduplication relies on redundant data for its effectiveness. Compression, on the other hand, optimizes all data, redundant or not. The combination of the two, especially when done in real time, can greatly reduce capacity consumption.

Where to use Real Time File System-based Deduplication

Most NAS file systems will allow real time data deduplication to be enabled on a per-volume basis; however there are some volumes that are more appropriate for deduplication than others. Probably, the data set with the highest return on investment remains backup data. With the speed of these systems, using a portion of the NAS storage pool to hold backup data is certainly appropriate, and can be a viable alternative to other solutions on the market.

Beyond backup data, probably the next best use case for deduplication on primary storage is the virtual server and/or the virtual desktop environment. All those server and desktop images have a significant amount of common data between them, including the operating system files and the application files. Storage efficiencies of 50:1 or greater are not uncommon when deduplicating virtual images.

After virtual images, user home directories are prime targets for optimization. There tends to be a measurable amount of redundancy between files as users collaborate and save different versions, while they are edited. Also, there tends to be a reuse of the same types of images and graphics between documents, like company logos for example. While the reduction is not often as significant there is typically a 5:1 improvement in storage utilization as a result of deduplication.

Summary: Real Time File System-based Deduplication is here to stay

When properly implemented within the NAS file system there can be a tremendous gain in storage optimization by using real time deduplication. This gain in optimization dramatically reduces storage purchasing and operational costs. Real time deduplication is typically simpler to manage since data is always stored in its optimized state. Finally, with proper architecting of the server hardware and its storage, this optimization can often be delivered without performance loss.

Open Storage and ZFS

What is Open Storage and ZFS

OpenStorage combines open source foundations including file systems and operating systems with purpose built storage management software and data center-class hardware and storage. The benefits to customers include the end to vendor lock-in and increased flexibility and ease of use that together are saving customers CapEx and OpEx. Previously Linux based OpenStorage solutions have generally not been perceived as truly enterprise class due to file system and kernel limitations.

The OpenStorage movement now achieves enterprise class capabilities thanks to the use of the extremely proven Solaris kernel and the revolutionary and now mature ZFS file system that provides enterprise-class unified storage capabilities by leveraging today’s high performance industry standard hardware. While many users such as Wikipedia use the ZFS file system as a part of OpenSolaris, the challenge for broad adoption has been harnessing the raw potential of this storage foundation into total solutions that are truly useful by corporate data centers.

Companies like Nexenta are leading the way by building total solutions that build upon ZFS and OpenSolaris while making it truly OpenStorage by working with their hardware and integrator partners to deliver total solutions that run on industry standard hardware, as opposed to the Sun hardware that customers are required to purchase when buying ZFS based storage from Sun.

These companies can expand the scope of ZFS beyond a mostly Oracle/Sun-supported effort by developing a broad ecosystem of open source projects, system integrator partners, top tier support vendors, and considerable in house development and engineering capabilities that have broken new ground particularly in the management of storage for virtualized environments.

ZFS is still at the core, however, and it’s important to understand what ZFS is and what it can do.

The Challenge with current File Systems

10 years ago the focus was on how to optimize storage for efficient database performance. While that is still an objective, attention has turned to the greater challenge of unstructured data, and the millions of files that are created every day. As a result of unstructured data, most filesystems are growing at an exponential rate and the cost to keep up with this expansion, both in terms of CAPEX and OPEX, is putting an immeasurable strain on an already thin data center. A new paradigm is needed to manage this growth.

The CAPEX perspective of this is obvious, without storage efficiency improvements from technologies like compression, thin provisioning, automated data placement and eventually deduplication, the costs to power and cool this storage are going to overwhelm the data center. Furthermore, there is an unsustainable chasm between the price raw storage and processor power is available for from manufacturers and the price charged for performance and capacity by the dominant storage vendors; this chasm is largely due to the customer lock-in enforced by the dominant vendors’ technologies and business models.

More subtle is the effect that these rapidly growing filesystems have on OPEX and their storage managers.

Managing a rapidly expanding environment with a proliferation of file based data  requires adding volumes, migrating users or growing and shrinking volumes. And yet today’s dominant file systems have limits on file size and on the number of items in a volume that are all too often encountered. When these limitations are faced users must either use an additional layer of volume management software to bridge these limitations or need to manually reconfigure their storage. In either case CAPEX and OPEX increases. Most file systems today were designed 10-15 years ago, when the amount of data stored was much less and the processors used to address and manage that data were 800-900 less powerful than today’s processors. Compromises that were reasonable at the time due to limited requirements and processor power constraints are now costing enterprises countless time and money.

An increasingly important driver of the growth of file based data is the shift towards virtualized server environments. After all, a virtual machine is a file with a set of associated storage. While it is possible to provide storage for virtualized environments via block level protocols, doing so in the face of the accelerating proliferation of virtual machines promises to further overwhelm already stretched storage administrators. As a result, there is a clear trend towards using NFS for VMware and other storage.

Finally, the need to manage separate protocols (iSCSI, Fibre, NFS, CIFS) across differing storage platforms puts pressure on both CAPEX and OPEX. Managing these storage protocols separately requires additional switching infrastructures, additional storage and of course, personnel to manage these different silos.

Modernizing the Filesystem

Most filesystems in use today were created long before we had shared storage, TB-sized drives, 10Gb networks and of course, server virtualization. What’s needed is a modern day filesystem for modern data storage challenges. A growing number of companies believe that filesystem is ZFS. Here’s why:

Unified Storage

ZFS can support NFS, CIFS, iSCSI. Companies can take ZFS and extend it. For example some companies now offer support for Fibre Channel protocols. What this means is that the storage manager can select one platform of storage without concern for which protocol to use if the original protocol changes or if another one is added later. Most storage projects start out with a specific protocol choice in mind but eventually, need a new one. This is one of the causes for so many different storage platforms in the data center. For example, a project can start out as CIFS for Windows file sharing, later add fibre channel for clustered Exchange support and then still have the requirement to add NFS for easier VMware deployment. This can now all be done from a single storage platform.

Data Management Flexibility

ZFS can provide unlimited snapshots and built-in RAID support with improved versions of Raid 5 and Raid 6. Unlike most traditional filesystems that have a hard limit on snapshots, meaning users must be mindful of snapshot reserve space, ZFS enables enough snapshots to provide a rollback point to the second, if needed. The way the ZFS filesystem is designed, it actually performs better with snapshots turned on.

The snapshot feature can be extended for use in a DR environment for asynchronous mirroring. Nexenta has added synchronous mirroring over IP which complements the asynchronous mirroring capabilities of ZFS and also search capabilities for retrieval of snapshots.

ZFS also provides both thin provisioning and storage pooling. Gone are the days of creating LUNs and carving up volumes. A storage pool is assigned to a group of NexentaStor servers with capacity minimums and maximums set. Then storage is allocated as it is needed.

This pooling of storage does not have to be on the same class of hardware. It can be Solid State Disk (SSD), SAS, Fibre or SATA, and it can all be tightly integrated in the data path. Additionally, data blocks can be automatically moved between tiers of storage as they age. This allows you to have your most active set of data on SSD while keeping your aging data on a less-expensive tier. With the rapidly dropping cost of flash-based SSDs this technology may quickly render Fibre channel and SAS obsolete.

For example, there are storage server products available from providers like Intel and Xyratex that will have 48 storage bays as well as PCI-E slots. Imagine using one of these systems, installing 48 – 1TB SATA drives, and then installing one of Texas Memory Systems’ PCI-E SSD Cards, with 480GBs of data, for less than $15,000. This would allow a system that delivers the most active data set almost instantly, yet could store years’ worth of information cost-effectively.

Storage Optimization

Part of ZFS’s storage optimization comes from the above-described storage pools and thin provisioning. But going further, a ZFS volume can also be compressed. Although deduplication won’t be available for a few months, a case can be made that compression is far more valuable on primary storage. For deduplication to have value, there must be duplicate data to begin with. For most primary storage tiers, that’s usually not the case. Compression, however, works on all data types, duplicate or unique, and in many cases, represents an overall space savings. Finally, compression of data, unlike deduplication, often causes minimal performance loss, making its use on real-time systems acceptable.

An exception to the deduplication payoff is when the storage is used for virtual machine images. ZFS however, has a potentially better way to optimize this storage and it comes without a performance impact – clones. Clones allow a snapshot area to be mounted and re-used in a read / write fashion. While this has value in test / dev environments, where it can really shine is in dealing with virtual server images. Instead of storing the same master image 100 times over, store it once, clone it and mount those clones to their respective virtual machines. The net result can be a significant increase in utilization.

For example, Nexenta has developed ‘VM Data Center’, which includes the ability to use a VM template to provision hundreds of identical VMs in under a minute, a feat that is not possible in non ZFS based solutions, including within VMware’s vSphere itself.   And those identical VMs take little more than the space of a single VM.

Data Availability

Finally, even the most feature-rich filesystem would be useless without a way to make data highly available. Once again, ZFS delivers a strong message and companies like Nexenta have enhanced it even further. It’s also more important than ever that something changes at the file system level. Uncorrectable Bit Error Rates, have stayed roughly constant, with an bad sector occurring as frequently as once every 8TBs. This is a problem for the storage manager because, while the UBER has stayed static, the capacity per drive and the number of drives in the data center has grown rapidly.  As a result, both silent (bit error bugs) and noisy (caused by tightly packed drive configurations) corruption have become more prevalent.

ZFS uses checksums stored in the parent block pointer of the data set to provide validation of the entire I/O path, protecting from both silent and noisy faults. This also protects the data from a host of potential drive-level issues, such as bit rot, phantom writes, misdirected reads and writes, DMA parity errors, driver bugs and accidental overwrite.

Finally ZFS has Self-Healing Mirrors and RAID-Z. Self Healing mirrors allow that if there is a corrupt block when reading from a mirror, it will validate that the second copy of that mirror is good and if it’s a re-write of that good copy it’s sent to the original mirror, automatically keeping data readable.

In RAID-Z, ZFS uses a dynamic stripe width to maximize drive utilization as it makes sense for each data block. Plus, all stripes are full strip writes, which eliminates the need for read-modify writes, as well as NVRAM (used by NetApp’s Data ONTAP),, keeping performance high and cost low. It can be both single or double parity (RAID 6) in write protection, which improves resiliency as it detects and corrects silent data corruption with checksums driving combinatorial reconstruction. At a high level, what has happened is that putting special purpose processors, RAID controllers, close to the disk is no longer useful now that processors are hundreds of times more powerful than they were when RAID was developed and an air tight software RAID solution plus true end to end data integrity checks is available as a part of ZFS.

In short, ZFS makes inexpensive disks safe and, combined with SSD PCI-E cards described above, can deliver optimal performance. Companies like Nexenta, that are building storage applications on the foundation of ZFS, gain a distinct advantage by not having to develop and test every aspect of the file system minutia. They, instead, can focus on extending the foundation to make it more usable to a broad cross-section of data centers.

With storage demand booming, especially for file based storage, a focus on the manageability of the potentially high performance ZFS based NexentaStor is paying off for Nexenta with rapid customer and partner adoption.

Vigor 2710 NAS feature

The Vigor 2710 Series’s USB port can now also be used to add storage memory to the unit in the form of a USB memory key (as shown above) or for higher capacity a USB hard drive. The Vigor 2710 then provides FTP access file uploading/downloading which can be from the local LAN or from anywhere on the Internet – ideal for a ‘simple to deploy’ file depository. Access can be ‘public’ or using usernames and passwords, each of which can have their own directories and/or file access rights. As well as FTP, file sharing is available as a Windows ‘network drive’. Using Internet Explorer, you can access, read and write the contents of the USB drive.

The new firmware (V 3.3.2) is available from Draytek UK downloads web page here: