While vi, emacs and nano are nice tools and are available on most Mac and UNIX/Linux machines, using them remotely means that all your personal editor settings might not be available on the remote machine, and if you share a common admin account to connect to the remote machine, you might not be allowed to copy your personal setting files over to the remote machine.

If you prefer your personal editing environment, you either need an editor application which supports opening an ssh connection to the target machine and then opening the file with the local editor settings (like BBEdit), or you need to mount the remote ssh system as a local filesystem and then use any local text editor you prefer (like vi, emacs, TextMate, etc.). The latter can be done using Fuse4X and sshfs. There are plenty of tutorials on the net how to set up Fuse4X and sshfs.

In BBEdit instead, just choose File -> Open from FTP/SFTP Server, then enter your ssh connection details:

Make sure you activate “SFTP”, as this tells BBEdit to use ssh instead of ftp.
Now you can browse the remote file system the same way you could using an ssh connection in Terminal:

Just browse to the file you are looking for and edit it the same way as it was a local file.

The tool is called WingFS and can be found on the brand new Archiware Technical Blog.

The tool is available for Mac OS X and is going to be released for Windows and Linux in Q1/2012, too.

While WingFS is cool as it is, I wonder if this is Archiware’s first step towards cloud integration of their commercial tools, too.

I agree with these companies that it can be very efficient to extend an existing infrastructure for Mac client management, as this allows you to use your support teams for this new task without big changes in organization, operation and infrastructure.

Using free Open Source tools allows Windows and Linux administrators to manage Macs in a similar way like with Apple servers or commercial third party solutions. (You can read more about it in my upcoming O’Reilly book, which I wrote with my co-author Harald Monihart – Harald works for Axel Springer, where he’s part of the team which integrates 12,000 Macs into a Windows environment)

The standard solution I use at most of my customers includes a little Python program and requires Web services as well as an SMB or AFP share and an Active Directory with an extended schema. Aside from these server-side services, the whole management process happens on an admin Mac client, so that your Windows team takes care for the availability of your Windows servers, while your Mac team takes care for the actual Mac client management – this way you maximize the usage of your admins’ specific know-how.

These are the main advantages of the solution I work with:

• It doesn’t matter if you use Windows, Mac or Linux servers – the Mac client management services run on all of them.
• There’s no licensing costs apart from Mac OS X Server or Windows Server costs.
• Your users can install software delivered by you without administrative permissions, so that they don’t need to be admin users – this increases the security level of your Mac environment.
• The GUI for your users is so easy to understand, that users either don’t need any training, or it doesn’t take longer than five minutes.
• This solution can be operated by separated Windows, Linux and Mac teams. It doesn’t matter if individuals understand both Windows and Mac OS X or if Mac and Windows know-how is spread across multiple people.
• Choose yourself how much internal and external resources you use – I provide consulting services to choose the best solution for your environment, help you build this solution, and train your admin team. My team and I also offer monitoring and operating of your Mac client management environment, so there’s a full choice of services from consulting to full-service operating available.
  Please get in touch to discuss your options.

The tools I use help you with the following tasks:

• Installation and upgrading of operating system and applications (mass deployment)
• Asset management
• Preferences management on user, group, computer, and computer list level
• Remote support of your users

If you need help managing Mac clients using Mac, Linux or Windows servers, I’d be happy to help.

For many companies it is important that their laptop users can access external networks for email and Internet access (e.g. at home, in the hotel or at a customer’s site) or because they need to access your customer’s server while they are on-site.

This means that most likely you let your users add network settings on their own.

Yet, in many companies you find both public Wi-Fi networks with internet access but limited access to a company’s internal network and an ethernet network with full access to the internal network but limited access to the outside world.

Due to security restrictions in these environments it is not allowed to build a bridge between the public Wi-Fi and the internal ethernet network.
But if you let your users change network settings on their own, how do you make sure, that they don’t build that bridge, either on purpose or by accident?

One way to do this is to use a free tool like crankd, which allows you to monitor your network devices and to trigger scripts whenever something changes. crankd has become part of the PyMacAdmin tools, so don’t get confused by the name PyMacAdmin.

In this little tutorial, we use crankd to monitor the ethernet and the Wi-Fi device in a MacBook Pro running Mac OS X 10.6.x. As soon as we get a working Wi-Fi connection, we deactivate our ethernet connection.

First, download and extract crankd.
Cd into the extracted folder and invoke
sudo ./install-crankd.sh
to install crankd on you machine.

Now, create the folder /usr/local/bin:
sudo mkdir -p /usr/local/bin

Create the file /usr/local/bin/toggleEthernet.sh:
sudo nano /usr/local/bin/toggleEthernet.sh

and copy the following code into it:

#!/bin/bash
AirPortStatus="$(/usr/sbin/networksetup -getairportnetwork en1)"
# echo "${AirPortStatus}"
if [[ "${AirPortStatus}" =~ "AirPort power is currently off." ]]; then
echo "AirPort not running. Activating Ethernet interface."
/usr/sbin/networksetup -setnetworkserviceenabled Ethernet on
elif [[ "${AirPortStatus}" =~ "Current AirPort Network:" ]] || [[ "${AirPortStatus}" =~ "You are not associated with an AirPort network." ]]; then
echo "AirPort is running. Deactivating Ethernet interface."
/usr/sbin/networksetup -setnetworkserviceenabled Ethernet off
fi
echo "========================="
(You can instead load the file from here.)

Save this script by typing Control-W, and close nano by typing Control-X.
Connect your test machine to working ethernet and Wi-Fi networks and run the script to see if it works.

If it works as expected, copy this file (after unzipping it, of course) into /Library/Preferences/.

The interesting part in this crankd preference file is:

SystemConfiguration
State:/Network/Interface/en1/AirPort
command: /usr/local/bin/toggleEthernet.sh

which means, that crankd listens to our AirPort interface and runs the script /usr/local/bin/toggleEthernet.sh whenever something changes.

To start the crankd daemon during system startup, please download this file, unzip it and copy it into /Library/LaunchDaemons.

Set the correct permissions:
sudo chmod 644 /Library/LaunchDaemons/de.andre-aulich.runcrankd.plist
sudo chown root:wheel de.andre-aulich.runcrankd.plist

and load the job:

sudo launchctl load -w de.andre-aulich.runcrankd.plist

Now AirPort should be turned off automatically as soon as you activate your ethernet connection.

Note: if someone connects a USB ethernet interface to your laptop, this will not be watched by our example crankd configuration. If you need to monitor multiple ethernet interfaces, you need to customize the configuration files described here.

Using the tools mentioned here, you can allow your laptop users to manage their network settings on their own without building a bridge between internal ethernet network and public Wi-Fi connection.

In short, I would say, that

• Apple opens up its pro software like FCP X and Mac OS X Server to the consumer, by making it easier to learn than ever before. A great strategy to sell more boxes and devices, which surely leads to greater turnover, and probably to more profit, too, as consumers buy easy tools and need support on a very low level only (if at all), which Apple can provide for cheap.
• Apple dumps all network products, which’s sole purpose was to help sell more client boxes to professionals in the enterprise or workgroup, like Xserves, Xserve RAIDS, Final Cut Server, and probably -on the long run- other products like Xsan metadata controllers and Mac OS X Server. In fact, I don’t think there is a big need for any of these products anymore, since Apple clients integrate just fine with Active Directory environments, most file servers, and many storage devices.
• I don’t think that this necessarily means Apple doesn’t care for the pros anymore. I think that FCP X is already quite powerful, and multicam support, FCP X APIs/XML interfaces, SDI connectivity and the like are going to be added to FCP sooner or later. Yet, I think Apple’s main market for FCP X is the single user or small workgroup. If you look at FCP X’s media import options, you’ll see the option “Create proxy media”: If you also look at the Sharing options: you’ll see that FCP X includes an option to export files and probably metadata to CNN iReport. I bet that FCP X’s powerful metadata management capabilities and the option to generate proxies during media import, are a very good basis to add iCloud support to FCP X. I guess that for many very small workgroups it would be great to simply send a proxy version of a project to the iCloud, so that another team member can edit a sequence and send it back to the original FCP X machine which has access to hires files to render the final output. This might be a very good Final Cut Server replacement for very small teams.

Making tools like FCP simpler than before doesn’t necessarily mean, that it’s not suited for pros anymore. Okay, right now it is not, but I am sure, it will soon be.

Yes, Apple has dumped Final Cut Server, which is the base for many postpro environments, now. But FCSvr meant to most of its customers, that you needed Xsan in place (most resellers and consultants were simply not able to design these systems right), that Open or Active Directory needed to work fine and that your Mac and Windows clients needed to be integrated into this directory infrastructure (and again, most service providers could not do these things properly).

This means it was very difficult to get a Final Cut Server infrastructure working, especially as so few people know how to make storage, asset management, Open or Active Directory, filesystem permissions, portable home directories and video editing clients work together smoothly.

In my opinion for many small shops it would be a great step to cut out all this overhead and move FCSvr into the cloud by adding an option to FCP X.

On the other hand, FCSvr leaves a big gap in the market, which tools like CatDV might fill: many shops do not want to publish their data into the cloud.
Especially in Europe people don’t like to store their business data on servers hosted either in the US or anywhere else by a US company, which might sooner or later grant access to these data to any kind of secret service.
This leaves a need for a local DAM in enterprise environments.

Personally, I would like to have a much easier DAM tool than anything on the market, something that can be set up without needing a consultant, at least for small environments. For bigger environments, I would say that if you work with FCSvr, you will be able to keep your current infrastructure and just replace either the FCSvr server software or probably the whole FCSvr machine to get something else up and running.

As FCSvr is so open, it is totally easy to export media and metadata to any other system.

I had a look at the new FCP X project files and the way FCP X stores files on a central storage. Even without the Apple API I think that there is a way to extract data easily and build them into your own asset management.

Being a consultant, my approach to Apple’s latest announcements is this:

• I recommend people to use Windows servers for directory management.
• Don’t know if Xsan will really be free in Lion. Still Xsan is a great tool, but I might recommend people to use StorNext metadata controllers at least if people need rack-mountable hardware.
• Apple builds wonderful standalone machines, which can be integrated into enterprise environments. In fact, now that Apple focuses on its core business – building great machines which are easy to use – and doesn’t care much about the enterprise network stuff around it, there’s more money in the game for third party developers who build DAM systems. I bet we’ll see great third party solutions soon and overall Apple kit will better fit into enterprise environments than today.

I feel that Apple’s approach on the pro market might leave us all with better tools in the end.
Let’s see.

Since Apple has discontinued the Apple Xserve in January 2011, there seems to be a growing need for rack mountable server hardware in the Apple world, which is more powerful than the Mac mini Server and takes less rack space and consumes less power than the Mac Pro.

If you want to run file services, directory services, software update services, and other services for Macs, Windows, and Linux clients, you’ll find both Linux and Windows based solutions to do just that. On the other hand, the Mac Pro and the Mac mini Server seem to be great systems to serve many of these things, too.

Yet, if you read the announcement of ActiveSAN, it seems as if there was a high demand for a 1U rack mountable metadata controller for Xsan environments.
What the guys at ActiveStorage seem to do is build great server hardware incl. nice monitoring and setup tools, which make it easy to set up a Quantum StorNext metadata controller to handle your Mac-based Xsan clients.

If you are an Xsan or StorNext pro anyway and work in the command line most of the day, you can even replace your existing Apple Xserve MDC with a Linux-based StorNext MDC with a minimal downtime of your Xsan volume. This is what you need:

• Server hardware which is able to run a recent Linux version. Make sure you add enough RAM, redundant drives for the boot disk, a nice and OS supported FC card, dual Gigabit Ethernet. Note: You can also use a Windows OS instead, which is nice if you integrate with Active Directory, but whatever you do, make sure, the OS of choice supports the LUN size you use in your Xsan setup. The ActiveSAN hardware looks like a very nice solution to this.
• I would go for CentOS as the MDC’s OS, as it’s officially supported by Quantum and doesn’t cost you money. If you need support, I would go for RedHat. See http://downloads.quantum.com/SNMS/4.1/StorNext%204.1%20Supported%20Platforms_V2.pdf for a list of supported MDC platforms.
• Make sure to integrate your MDC into your directory environment. Both Active Directory and Open Directory are supported. You will need this to use ACLs (the only way to properly deal with permissions in most Xsan environments).

Before you start buying the hardware to build the new MDC, you need to make sure, that you don’t have named streams enabled in your existing Xsan environment.

To actually migrate the volume from the Xsan MDC to the SNFS MDC, roughly follow these steps:

• Make sure to use matching filesystem versions in the Xsan environment and on your StorNext controllers.
• Run cvfsck -w on the Xsan volumes.
• On the primary Xsan metadata controller, save the folder /Library/Filesystems/Xsan/config to a place we can access easily later on, like a USB stick, e.g.
• Shut down the Xsan metadata controllers.
• Set up the StorNext controllers. The easiest way is to use the same IP addresses as for the Xsan metadata controllers.
• After installing the StorNext filesystem and -optionally- the Storage Manager, copy our Xsan volume’s config file into the StorNext controller’s config folder.
• Open the config file and delete the lines with the options “NamedStreams”, “EnableSpotlight”, and “SpotlightSearchLevel”.
• Optionally, make the volume managed by adding the appropriate option to its config file.
• Make sure to run chown www:adic on the config file as well as chmod 664
• Run cvfsck on the volume.
• Start the volume and mount it.
• You are done.

If you want to add Xsan clients to your StorNext controller, you find a nice article at http://krypted.com/xsan/adding-xsan-clients-to-stornext-environments/.

While this migration is something that can be done very easily, you need to consider, that StorNext currently doesn’t support Spotlight searches, so you can’t easily use the Finder to search for content. If your users navigate through the filesystem or use a DAM like Final Cut Server, this is not an issue at all. (On the other hand, the StorNext MDC catches all filesystem events, so I guess it should be possible to write a client, which collects these events and tells a dedicated Mac machine to add new files to the filesystem’s central Spotlight DB).

Another caveat is that the automatic HSM process in Storage Manager, which moves data to tape and restores them to disk as needed, restores data whenever a file gets invoked by a client. You either need to turn off previews in Finder to prevent constant restores, or you better hide the filesystem from the Finder and let your users access the filesystem through FCSvr and its edit-in-place option only.

One of the best things that come with the migration from Xsan to StorNext is that you can add additional functions (part of SNFS and/or SNSM) like filesystem replication, Distributed Data Mover, HSM functionality, writing to tape, etc.

In addition, SNFS has documented optimization settings for image sequences, which is very interesting for film production.

On the other hand, if you already own an Xserve which runs your Xsan, I would say that this is a great hardware to do just that.

Although I have done the migration described here in the lab, and found it reasonably easy, I am curious to see ActiveSAN as soon as it’s there, because it looks like they made the process of building a new Xsan/StorNext environment so much easier.

So better than setting it to automatic mode and let it run every hour, we can schedule our Time Machine backups. While there are some nice GUI applications available for this task, this article explains how you can do this using onboard tools like AppleScript and iCal.

This is a nice and easy one, so don’t be afraid to go on reading.

First, we need to set up Time Machine in System Preferences:

This screenshot assumes that you have already chosen the backup volume. Under Options choose files, folder, and/or volumes which you don’t want to backup.
The most important part, though, is that you TURN OFF Time Machine. Otherwise it would run every hour, which we are trying to change here.

After this, we can invoke Time Machine manually, which you can either do by using the Time Machine menulet:

or by opening the Terminal application in /Applications/Utilities/Terminal, and typing


/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper


Either of this would trigger your Time Machine backup, while both methods would invoke the latter command in the background.

Now let’s use this command and make it executable by iCal.

First, open /Applications/AppleScript/Script Editor, then enter the following text and save the file as a script called Backup:

tell application "Terminal"
do shell script "/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper"
end tell


This should now look like this:

Hit Run in Script Editor to see if your little application works.

If it does, you can now go to iCal and open its Settings panel.
Make sure, that in the advanced panel the options “Turn off all alarms” and “Turn off alarms only when iCal is not open” are not active.
This makes sure, that your backups will run no matter if iCal is running or not.

Yet, the whole story only works as long as your current user is logged in to the GUI of your machine, so you might want to activate automatic login for your user (or you don’t, as you like).

Now create a new iCal event (which might be created in a dedicated Backup calendar):

The trick here is to set up an alarm and use “run script” as the alarm action. Now select your Apple Script which you have just created and save your choice.
Schedule this event to a time at which you don’t work, and set up the recurrence rule.

Voilà! You’re done!

While this is quite easy, I’ve got some customers who want to replace their existing Apple Xserve RAIDs with 4Gb, redundant-controllers PROMISE RAIDs at the same time.

I choose the following way to do the whole thing:

• Upgrade your existing Xsan environment to the latest Mac OS X 10.4.x/ Mac OS X Server 10.4.x version and upgrade to Xsan 1.4.2.
• Do a quick cvfsck on your volume, if necessary invoke cvfsck -w.
• Now rename /Library/Filesystems/Xsan/config/XsanVolumeName.cfg to /Library/Filesystems/Xsan/config/XsanVolumeNameOld.cfg.
• In /Library/Filesystems/Xsan/config/fsmlist change XsanVolumeName to XsanVolumeNameOld.
• Fix the ICB mismatch by invoking cvfsk -w in interactive mode. This and the above two steps are explained at Xsanity.
• Now copy the MDC’s directory /Library/Filesystems/Xsan/config/ to an external device.
• Install Leopard on the MDC, upgrade it to the latest version, and install Xsan 1.4.2 on it, too. Enter a valid Xsan serial number in Xsan Admin (Xsan 2 license works with Xsan 1.4.2, too).
• Mount the existing volume to see if it still works. Now unmount it, stop the volume, and install Xsan 2.
• If you open Xsan Admin the Xsan Assistant starts up and asks you for some self-explaining data. After that your volume can be mounted again. Try if it still works and then deactivate and stop the volume again.
• Again, cfsck the volume.
• Now you can set up your new device, mount it using your old device’s original volume name and copy the data over to the new storage.
• After you copied the data to the new device, delete the old Xsan volume and remove it physically.
• Now install Leopard on all FC connected machines as well as Xsan 2 and integrate them with you new Xsan volume.

Hope this helps.

USE AT YOUR OWN RISK !!

]]> http://www.andre-aulich.de/en/perm/how-to-update-a-104xsan-142-mdc-to-105xsan-2-and-replace-the-raid-hardware-at-the-same-time/feed 0 http://www.andre-aulich.de/en/perm/additional-config-script-for-xsan-2-certified-promise-raids-and-for-the-uncertified-ones-too http://www.andre-aulich.de/en/perm/additional-config-script-for-xsan-2-certified-promise-raids-and-for-the-uncertified-ones-too#comments Mon, 07 Apr 2008 12:51:02 +0000 André Aulich http://www.andre-aulich.de/en/perm/additional-config-script-for-xsan-2-certified-promise-raids-and-for-the-uncertified-ones-too Continue reading →]]> When you create a second (third, fourth,…) storage pool in your Xsan volume and use the Apple Xsan 2 certified Promise RAIDs, you might only want to create data LUNs on these RAIDs, as you already store your metadata for this volume somewhere else.

Apple and Promise provide you with config scripts for the Promise RAIDs, of which one is supposed to configure pure data LUNs for Xsan environments.
You find their script here (works with SATA drives).

Yet, if you look at the script, you will see, that this part

array -a add -p 13,14,15 -s "alias=Scratch1" -c 1 -l "alias=Scratch1,raid=5,readpolicy=readahead,writepolicy=writeback, preferredctrlid=1"

creates a third LUN on your RAID, which is made of three disks working as RAID level 5. This LUN, called “Scratch”, co-exists with two other LUNs, named “Data1″ and “Data2″, which contain six disks each.

If two Promise RAIDs make one Xsan volume, you would probably use this script to configure the first RAID with two mirrored disks for metadata, six RAID 5 disks for LUN Data1, six RAID 5 disks for LUN Data2, and two global hotspare disks.
If now you add a second RAID, you need to configure LUNs of the same size like the ones on the first RAID.

That’s why Apple’s script for data only RAIDs creates to six disks RAID level 5 arrays.
As this leaves us four empty disks, Apple decided to create a third LUN based on three disks, which then you can format using HFS+ for Final Cut Pro project files (You would then use zoning on your FC switch to mount this scratch LUN on one machine only, which uses AFP to reshare this volume with your FCP clients). Also, this leaves one more disk free, which is then set up as a global hotspare disk.

Though this thinking is completely correct, some of us might want to add Promise RAIDs to an already existing Xsan volume. If your older RAIDs are Apple Xserve RAIDs, you might want to create an extra storage pool for your Promise RAIDs (see http://support.apple.com/kb/HT1110).

Probably you don’t want to create the third scratch LUN on each of your RAIDs if all you need is more sped and capacity for your Xsan volume.

So open up Apple’s config script in your favorite text editor (vi, nano, BBEdit,…), and do the following:

• Change array -a add -p 1,2,5,6,9,10 -s "alias=Data1" -c 1 -l "alias=Data1,raid=5,readpolicy=readahead,writepolicy=writeback, preferredctrlid=1" to array -a add -p 1,2,5,6,9,10,13 -s "alias=Data1" -c 1 -l "alias=Data1,raid=5,readpolicy=readahead,writepolicy=writeback, preferredctrlid=1"
  During import this will later create the first seven disks RAID level 5 data LUN.
• Change array -a add -p 3,4,7,8,11,12 -s "alias=Data2" -c 1 -l "alias=Data2,raid=5,readpolicy=readahead,writepolicy=writeback, preferredctrlid=2 to array -a add -p 3,4,7,8,11,12,14 -s "alias=Data2" -c 1 -l "alias=Data2,raid=5,readpolicy=readahead,writepolicy=writeback, preferredctrlid=2
  This will later create the second seven disks RAID level 5 data LUN.
• Delete array -a add -p 13,14,15 -s "alias=Scratch1" -c 1 -l "alias=Scratch1,raid=5,readpolicy=readahead,writepolicy=writeback, preferredctrlid=1"
  Now the script won’t create the scratch LUN anymore.
• Change spare -a add -p 16 -t g -r y to spare -a add -p 15,16 -t g -r y
  This will set up two hotspare drives.
• To make it perfect, delete init -a start -l 2 -q 100
  This wil prevent the script from trying to initialize the scratch LUN (which will not be created by our script).

All commands you find in the Apple config scripts can be either imported as a script via the GUI or manually entered in the CLI of the RAID.
They even work with the original Promise VTrak E610f RAIDs.

Yet, make sure you upgrade your Promise RAID’s firmware to 3.28.0000.00 before you import the script, otherwise with 3.22.0000.00 it will not understand the part hostcacheflushing=disable, additionally config script import will only be possible on the CLI with older firmware versions. (BTW, the Apple certified Promise RAIDs come with 3.29.0000.00 pre-installed, which can not be downloaded from the Promise site).

ATTENTION: USE THIS INFORMATION AT YOUR OWN RISK!

]]> http://www.andre-aulich.de/en/perm/additional-config-script-for-xsan-2-certified-promise-raids-and-for-the-uncertified-ones-too/feed 0