[Casper] Upgrading from Tiger to Leopard
Miles Leacy
miles.leacy at themacadmin.com
Tue Jan 6 09:01:43 PST 2009
On Tue, Jan 6, 2009 at 11:27 AM, Thomas Larkin <tlarki at kckps.org> wrote:
> Users could jack it up them self as well since they own everything.
>
They own /Users/<username>. They don't own /Users. <username> should not
be able to affect the /Users symlink. If your users are admins, you've got
a host of problems and I suggest making a policy stating that no one is an
admin ASAP. That's a separate discussion though.
On Tue, Jan 6, 2009 at 11:27 AM, Thomas Larkin <tlarki at kckps.org> wrote:
> I saw so many weird quirks with it when we ran Tiger, and a lot of times it
> would dupe local or mobile accounts to the machine and I would have to go in
> and delete one of them to make the account work again.
>
This was a netinfo issue. As far as I know, it does not occur in Leopard's
local ds. Nicole Jacque from Apple distributed a lovely script to handle
this issue. I'll paste it at the end of this message. I run this script as
a policy triggered by every15 on a smart group consisting of all tiger
machines.
On Tue, Jan 6, 2009 at 11:27 AM, Thomas Larkin <tlarki at kckps.org> wrote:
> I don't think diskutility supports live resizing in Tiger
>
It doesn't. If you're migrating to Leopard, one of the first things I
suggest is to create a Leopard diagnostic/utility/imaging image. If you
boot your Tiger system from an external drive imaged with this Leopard
image, you can take advantage of Leopard's diskutil command and its live
resizing options.
Plus with all the hard drive failures I see anyway every day on the
> Macbooks, I would really suggest using mobile home directories. Then you
> can just wipe and resync the home directory and call it a day.
>
Network homes have never been an option in the environments I've worked
with. The network infrastructure or storage infrastructure (or both) has
been a show-stopper. Also, if you go this route, you need to resync the
entire home directory after a reimage. With a separate data partition, you
don't lose time to file copying. I'm not saying network homes are bad, just
that they don't solve the problem of time lost to data copying.
On Tue, Jan 6, 2009 at 11:27 AM, Thomas Larkin <tlarki at kckps.org> wrote:
> When you toss these in your production machines, are these servers or are
> these like actual user machines?
>
I only do this for client machines. Servers have a single "Server HD"
system volume with a default /Users path. I put any service data and/or
share points on enterprise storage volumes.
On Tue, Jan 6, 2009 at 11:27 AM, Thomas Larkin <tlarki at kckps.org> wrote:
> I think working in education has made me paranoid since students like to
> tinker, hack, exploit, and crash machines whenever they can.
>
I've worked in K-12 and I agree with you. Unfortunately, adults aren't
always any better. I've had to come up with almost as many interesting
management policies and processes in the corporate world as I did in
education. A good mix of permissions, MCX and Casper policies should
prevent and/or revert any unauthorized tinkering.
# Script to remove 'disabled user' records from local directory
# This should work in both Tiger and Leopard
# Run this script as root or with sudo
#!/bin/sh
for cuser in `dscl . -list /Users AuthenticationAuthority | grep
DisabledUser | awk '{print $1}' | tr '\n' ' '`; do
dscl . -delete /Users/$cuser
done
----------
Miles A. Leacy IV
Certified System Administrator 10.4
Certified Technical Coordinator 10.5
Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com
On Tue, Jan 6, 2009 at 11:27 AM, Thomas Larkin <tlarki at kckps.org> wrote:
> I guess I would rather do it in DS than by a sym link just because. Sym
> link goes bad lots of problems I think could happen. Users could jack it up
> them self as well since they own everything. Especially with NetInfo. I
> saw so many weird quirks with it when we ran Tiger, and a lot of times it
> would dupe local or mobile accounts to the machine and I would have to go in
> and delete one of them to make the account work again. I guess I am just a
> bit paranoid, and I don't like touching anything in production. I would
> have to fully test the sym link thing heavily before I did it in my live
> environment. It is good to know it works for you, maybe some day I will try
> it.
>
> Also, with laptops I don't think diskutility supports live resizing in
> Tiger, so you would have to be a bit more creative because you couldn't have
> a second volume nor could you script something to create a new volume on the
> existing drive in Tiger. I think that is one of the 300 new features of
> Leopard if I recall, to resize live partitions and create a /users partition
> to house the directory.
>
> Plus with all the hard drive failures I see anyway every day on the
> Macbooks, I would really suggest using mobile home directories. Then you
> can just wipe and resync the home directory and call it a day. The down
> side to that is that a home sync is not a true back up, it is a
> synchronization, which some users just can't quite grasp.
>
> When you toss these in your production machines, are these servers or are
> these like actual user machines? I think working in education has made me
> paranoid since students like to tinker, hack, exploit, and crash machines
> whenever they can.
>
>
>
> ___________________________
> Thomas Larkin
> TIS Department
> KCKPS USD500
> tlarki at kckps.org
> blackberry: 913-449-7589
> office: 913-627-0351
>
>
>
>
>
> >>> "Miles Leacy" <miles.leacy at themacadmin.com> 01/06/09 9:52 AM >>>
>
> I've been doing this in production environments (large enterprises as well
> as my family's Macs) for at least two years on both Tiger and Leopard
> without any issues. What are the potential issues you're concerned about?
>
>
> The reason for including the permissions repair is lost to antiquity and
> poor documentation I'm afraid, but I seem to vaguely recall it having
> something to do with the /Users/Shared folder. Since it works, I'm not
> overly concerned with uncovering the answer, but if you care to, you could
> comment out the permissions repair line and see what the difference is.
>
>
> Whether netinfo or ds is handling your home folders, it refers to them
> as a filesystem path. As far as my knowledge and experience goes, there is
> no difference in how home folders function between a system with a genuine
> /Users path and one with a symlinked /Users path.
>
>
> ----------
> Miles A. Leacy IV
>
> Certified System Administrator 10.4
> Certified Technical Coordinator 10.5
> Certified Trainer
> Certified Casper Administrator
> ----------
> voice: 1-347-277-7321
> miles.leacy at themacadmin.com
> www.themacadmin.com
>
>
>
>
> On Tue, Jan 6, 2009 at 10:28 AM, Thomas Larkin
>
> <tlarki at kckps.org>
>
> wrote:
>
>> I don't know if I think that is a totally wise idea. I have read on
>> several occasions either at AFP548.com or macenterprise.org about moving
>> home directories and then connecting them by symbolic link. While I can't
>> exactly recall the specifics other than it has to do with NetInfo and the
>> location of the home directory or with Open Directory (dscl in 10.5) and how
>> the user database actually points to the home folder. Also, if I recall
>> diskutility will not repair permissions on user data, it only does it on
>> system data. I am not saying it won't work, I am just saying there may be
>> some issues as I have read from other people posting and how NetInfo and
>> Open Directory handle the user database. Please correct me if I am wrong on
>> that, because I have never tried to make a user partition on a local machine
>> just for home directories, well at least not in OS X. In Linux I have.
>>
>>
>> If you don't have network homes, or portable home directories I really
>> strongly suggest you look into something like that. I know that 10gigs of
>> data for each user can eat up storage pretty quick, but storage is actually
>> well, kind of cheap these days.
>>
>>
>> Over the summer we reimaged 6,000 Macbooks from 10.4 to 10.5. 10.5.4
>> was a damn nightmare but 10.5.5 smoothed most of those things out. I wiped
>> out all of our servers, reloaded them, and since I house home directories on
>> separate volumes on the network I just pointed in WGM the volume for home
>> directories. I also recommend a full wipe and fresh import of LDAP. I just
>> exported mine to plain text (users and groups) and then reimported them via
>> WGM. This will not preserve passwords, so I did a master password reset. I
>> have tools now to set unique passwords for users as well, and will be
>> implementing that over next summer. Next summer I am wiping out everything
>> and freshly loading every thing.
>>
>>
>> ___________________________
>> Thomas Larkin
>> TIS Department
>> KCKPS USD500
>> tlarki at kckps.org
>> blackberry: 913-449-7589
>> office: 913-627-0351
>>
>>
>>
>>
>>
>> >>> "Miles Leacy" <miles.leacy at themacadmin.com> 01/06/09 8:01 AM >>>
>>
>>
>> If you don't mind doing some extra work now, you can move people's data to
>> another partition now, and in the future, you can do as you like with the
>> system volume going forward without worry about user data.
>>
>>
>>
>> Note that if you boot an existing Mac (with user data) to a Leopard
>> volume, you can create new partitions non-destructively and this task can be
>> scripted.
>>
>>
>> I would (and do) do it like this:
>>
>>
>> #!/bin/sh
>>
>> #
>>
>> ##### HEADER BEGINS #####
>>
>> # scr_sys_symlinkUsers.sh
>>
>> #
>>
>> # Created 20071011 by Miles A. Leacy IV
>>
>> # miles.leacy at themacadmin.com
>>
>> # Modified 20090106 by Miles A. Leacy IV
>>
>> # Copyright 2009 Miles A. Leacy IV
>>
>> #
>>
>> # This script may be copied and distributed freely as long as this header
>> remains intact.
>>
>> #
>>
>> # This script is provided "as is". The author offers no warranty or
>> guarantee of any kind.
>>
>> # Use of this script is at your own risk. The author takes no
>> responsibility for loss of use,
>>
>> # loss of data, loss of job, loss of socks, the onset of armageddon, or
>> any other negative effects.
>>
>> #
>>
>> # Test thoroughly in a lab environment before use on production systems.
>>
>> # When you think it's ok, test again. When you're certain it's ok, test
>> twice more.
>>
>> #
>>
>> # This script moves /Users to /Volumes/Data. If your data volume is named
>> differently,
>>
>> # be sure to replace each instance of "/Volumes/Data" with the path to
>> your data volume.
>>
>> # Run as an "at reboot" script when imaging with Casper.
>>
>> #
>>
>> ##### HEADER ENDS #####
>>
>>
>> /bin/mv /Users /Volumes/Data
>>
>>
>> rm -R /Users
>>
>>
>> /bin/ln -s /Volumes/Data /Users
>>
>>
>> diskutil repairPermissions /
>>
>>
>>
>> ----------
>> Miles A. Leacy IV
>>
>> Certified System Administrator 10.4
>> Certified Technical Coordinator 10.5
>> Certified Trainer
>> Certified Casper Administrator
>> ----------
>> voice: 1-347-277-7321
>> miles.leacy at themacadmin.com
>> www.themacadmin.com
>>
>>
>>
>>
>> On Mon, Jan 5, 2009 at 4:10 PM, David Lundgren
>>
>> <david.lundgren at brooks.edu>
>>
>> wrote:
>>
>>> I was wondering how you all have done migrations from Tiger to Leopard.
>>>
>>> We have an Active Directory setup where the users home directories are
>>> local
>>> to the machine (our faculty often have 10GB+ of data, and some have
>>> laptops).
>>>
>>> We were contemplating doing separate user and OS partitions at the same
>>> time
>>> to make any future OS upgrades less painful, without having to worry
>>> about
>>> user data.
>>>
>>> Thanks,
>>>
>>> David Lundgren
>>> IT Systems Administrator
>>>
>>> Brooks Institute - "Passion, Vision, Excellence"
>>> 27 East Cota Street
>>> Santa Barbara, CA 93101
>>> (888) 304-3456 (toll-free)
>>> (805) 690-7615 (office)
>>> http://www.brooks.edu
>>>
>>> _______________________________________________
>>> Casper mailing list
>>> Casper at list.jamfsoftware.com
>>> http://list.jamfsoftware.com/mailman/listinfo/casper
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.jamfsoftware.com/pipermail/casper/attachments/20090106/e20f8843/attachment.html
More information about the Casper
mailing list