Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Encrypted backup using sparse image - Issue




On Apr 20, 2008, at 3:29 PM, Demetri wrote:

What makes crontab "right" and other approaches wrong?

Your iCal-oriented approach is definitely interesting, and even 'cool' as an experiment in automation and integration.


The main problem I see is that it's highly complicated with many inter-dependancies, as compared to a low-level automated backup solution using unix tools. At the end of the day, the simplest functional solution has a distinct advantage over everything else due to the simplicity. "Fewer moving parts" has all sorts of good connotations like "less likely to break" and "easier to fix if it breaks".

I think part of the issue is that the 'simplest functional solution' has nothing to do with the humans who are involved, but merely with the nature and capabilities of the available tools. Configuring cron or launchd might not seem simple to someone who is unfamiliar with either, whereas an avid AppleScript / iCal user might find configuring those tools much easier. When I say 'simple', I'm speaking from a systems perspective, not an 'ease of use' perspective.

There is a tendency for administrators to stick with what they know when it comes to rolling things into a production environment, and that's not necessarily a bad thing. Problems may arise when the desire to use a known solution outweighs the desire to investigate the suitability of other solutions.

This particular issue highlights the differences in style between unix admins and Macintosh admins. For the Mac admin, reliance on userspace and GUI tools is typically a given, both for the apps they support and for administrative processes. For unix admins, the opposites are often true. Mac OS X Server allows administrators to mix both styles in the same environment, so there are often several different ways to get a given job done.

From a simplicity and reliability perspective, low-level unix tools are far and away a better choice as compared to anything in a GUI environment. The amount of software required to produce a functional GUI login session is far greater than that which is required to support low-level unix tools.

As a demonstration, use the developer tool 'otool' to compare the shared library requirements of crontab and loginwindow.

{2} andre@dude [~] % otool -L /usr/bin/crontab
/usr/bin/crontab:
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.3)


{3} andre@dude [~] % otool -L /System/Library/CoreServices/ loginwindow.app/Contents/MacOS/loginwindow
/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow:
/System/Library/Frameworks/DiskArbitration.framework/ Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/SystemConfiguration.framework/ Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/ Security (compatibility version 1.0.0, current version 29774.0.0)
/System/Library/PrivateFrameworks/Admin.framework/Versions/A/ Admin (compatibility version 1.0.0, current version 1.0.0)
/System/Library/PrivateFrameworks/AFPDefines.framework/ Versions/A/AFPDefines (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ApplicationServices.framework/ Versions/A/ApplicationServices (compatibility version 1.0.0, current version 22.0.0)
/System/Library/Frameworks/SecurityFoundation.framework/ Versions/A/SecurityFoundation (compatibility version 1.0.0, current version 28150.0.0)
/System/Library/PrivateFrameworks/URLMount.framework/ Versions/A/URLMount (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libbsm.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/PrivateFrameworks/FileSync.framework/ Versions/A/FileSync (compatibility version 22.0.0, current version 22.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/ AppKit (compatibility version 45.0.0, current version 824.42.0)
/System/Library/PrivateFrameworks/ServerControl.framework/ Versions/A/ServerControl (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/ Foundation (compatibility version 300.0.0, current version 567.29.0)
/System/Library/PrivateFrameworks/DisplayServices.framework/ Versions/A/DisplayServices (compatibility version 1.0.0, current version 1.0.0)
/System/Library/PrivateFrameworks/MachineSettings.framework/ Versions/A/MachineSettings (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/DirectoryService.framework/ Versions/A/DirectoryService (compatibility version 1.0.0, current version 309.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9)


The upshot is that loginwindow has far more moving parts, and we haven't even launched a GUI app yet.

The fact that your supported server apps require a GUI login session should be seen as a liability, not as a convenience, and this should not be used as an excuse to base other administrative processes on high-level GUI tools in the cases where reliability is paramount. This statement is based on many of the software design principles you can find in the great book "The Art of Unix Programming", freely available online at: http://www.faqs.org/docs/artu/ - it's really good stuff even for non-programmers, as a fast path towards understanding design patterns that have been successful for decades. In my own system administration experiences, I have found much of the content of that book to be directly applicable to common sysadmin tasks.

Finally, I don't want it to sound like I'm poo-poo'ing GUI stuff (lol). Seriously though, I use GUI tools all the time. The point of all this is to use tools appropriate for the job, and in the case of server backups, 'reliability' easily trumps 'ease of configuration'.

Hope this helps,
-Andre


V/R, Wm. Cerniuk

Sent from my iPhone

On Apr 20, 2008, at 17:40, David Haines <email@hidden> wrote:


On Apr 20, 2008, at 2:34 PM, John C. Welch wrote:

On 4/20/08 11:54 AM, "John Slaughter" <email@hidden> wrote:

If you want, you can do this all visually from a central system using
iCal and triggering AppleScript apps to execute at the servers over
the network. Each server then is controlled from the centralized
calendar and performs its own backup leveraging multiple processors
for multiple backups.

Um...no, and no. iCal is most DEFINITELY not the proper mechanism to
manage
scheduled backups for servers. That's what things like cron and
launchd are
for. Ical's background scheduler only runs in user space, and you'd
have to
set up mechanisms for the AppleScript to run the backups on multiple
machines.


This reeks of "not the way to do it" from a reliability standpoint.

I'm with Demetri when it comes to (at least) providing people with
options. How many people are running Filemaker Server with a user
already logged in? (Too many, but still.) It may not be an option
to you, but it may be an option for some.


I've seen too many people crushed by "but Cron was supposed to be
backing up daily."   It has it's problems too.

There are two mechanisms to use here that are specifically designed for
this: cron and launchd. The fact that neither are absolutely perfect does
not mean that they should be ignored in favor of a method that is not even
close to designed for this purpose.


What happens if the machine running iCal reboots for some reason? Your timed
job doesn't run. Cron and launchd, not *having* to run from a user login
don't have that particular problem


As a test method for the SuperDuper parts, sure, iCal's a good test. As a
method I want backing up my SERVERS???


Um...no


Couldn't agree more.

Doing things the wrong way - no matter how much easier it might seem or feel - is never a good choice.
If the issue is (perhaps) not wanting to deal with the very non- click-and-point aspects of cron and launchd, that's about as poor a reason for failing to use them as it gets.
There are many available tutorials on Cron and some fine articles on launchd at afp548.com.


But if you really must, there's Cronnix (for cron) and Lingon (for launchd) - I never ever use the former and only rarely use the latter.
What problems with cron ? There was a bug very early in 10.4 that's long since gone. I hope you're not running 10.4.0 on anything : )
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/m4c0b1% 40gmail.com


This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden

This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Macos-x-server mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macos-x-server/email@hidden

This email sent to email@hidden
References: 
 >Re: Encrypted backup using sparse image - Issue (From: "John C. Welch" <email@hidden>)
 >Re: Encrypted backup using sparse image - Issue (From: David Haines <email@hidden>)
 >Re: Encrypted backup using sparse image - Issue (From: Demetri <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.