Shirt Pocket Discussions

Shirt Pocket Discussions (https://www.shirt-pocket.com/forums/index.php)
-   General (https://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   scheduling an unattended backup on MacOSX server (https://www.shirt-pocket.com/forums/showthread.php?t=1799)

gmachen 01-29-2008 10:28 AM

And why does the cron task for the root account not get removed when the SD! schedule is deleted?

dnanian 01-29-2008 10:31 AM

Yes, this is something we've not heard of. Scheduling doesn't really do anything that might lock a volume.

Try running something like:

Code:

sudo lsof | grep "The-Volume-Name"

dnanian 01-29-2008 10:32 AM

I believe it does when you quit SD.

gmachen 01-29-2008 01:20 PM

75-94-82-80:~ george$ sudo lsof | grep "The-Volume-Name"

WARNING: Improper use of the sudo command could lead to data loss
or the deletion of important system files. Please double-check your
typing when using sudo. Type "man sudo" for more information.

To proceed, enter your password, or type Ctrl-C to abort.

Password:
75-94-82-80:~ george$


So nothing came up. I'm still not out at my server site, but rather did this on my laptop, but I would think that it would have listed processes associated with my bootup drive, no? ("Macintosh HD")

Any other ideas, or syntax, or a GUI utility?

--
<SeinfeldParaphrase>
These (Unix) pretzels are making me thirsty!
</SeinfeldParaphrase>

gmachen 01-29-2008 01:25 PM

>> And why does the cron task for the root account not get removed when the SD! schedule is deleted?

> I believe it does when you quit SD.

I'll repeat the exercise when I go back out to the sever site, then report back here, but I vividly recall quitting, SD!, restarting, and having to download CronniX to inspect root's crontab, and having to delete the task.

chris_johnsen 01-29-2008 02:20 PM

Quote:

Originally Posted by gmachen (Post 16848)
75-94-82-80:~ george$ sudo lsof | grep "The-Volume-Name"
75-94-82-80:~ george$


So nothing came up. I'm still not out at my server site, but rather did this on my laptop, but I would think that it would have listed processes associated with my bootup drive, no? ("Macintosh HD")

Do you mean that you used the name of your boot volume in the place of "The-Volume-Name" on the command line? If so, that likely will not display anything because the name of the boot volume does not show up the POSIX paths that lsof displays (the boot volume is just "/").

My preferred lsof invocation is sudo lsof /path/to/volume/root. For the boot volume this would be sudo lsof / (which will probably print out something from every process on the system!). For most other non-boot volumes it looks like sudo lsof /Volumes/mountedVolumeName. If the volume name has spaces or special characters in it, it will need to be quoted (try putting single quotes around it, which will work as long as the volume name does not have any single quotes in it; or just use the shell's filename completion by typing enough characters to disambiguate the name and then hit TAB, it will automatically escape any special characters for you).

You can test it out by creating a little sparse image (or using any disk image you might have laying around). Mount the image and open a Finder window to the volume itself or some folder in it. Then run the lsof command. You should see an entry for Finder displayed.

dnanian 01-29-2008 03:00 PM

Good advice from Chris... although the problem here wasn't that the boot volume couldn't be ejected (that's pretty obvious).

Rather, you need to actually substitute your volume name for "The-Volume-Name".

chris_johnsen 01-29-2008 07:54 PM

Ahh, yes. I missed that interpretation. I thought maybe gmachen was testing out the lsof | grep … command using the boot volume name on the laptop as a "trial run" before getting back to the server. But the copy-and-paste of the Terminal output could have been verbatim (not a "sanitized" version) meaning the grep was searching for a made-up volume name.

gmachen 01-30-2008 09:47 AM

Quote:

Originally Posted by pch (Post 15473)
... would ... the following work?
run the SD! gui client as root using sudo (not sure whether the difference between effective and actual uid would matter)...

Quote:

Originally Posted by dnanian (Post 15474)
You'll need to log in as root and schedule that way. You can then disable root login again.

Just to be completely clear, are you saying that scheduling SD! launched as root via sudo from a regular admin account (with the root account login access remaining disabled) would not work, but rather one actually has to login as root?

If so, I'd be academically curious as to what's the difference. Thanks!

dnanian 01-30-2008 09:53 AM

I'm pretty sure that running with "sudo"ed root permissions but from a login session as another user won't set your Home and other items to that user's account for graphical apps.

gmachen 01-30-2008 10:37 AM

Quote:

Originally Posted by dnanian (Post 16864)
I'm pretty sure that running with "sudo"ed root permissions but from a login session as another user won't set your Home and other items to that user's account for graphical apps.

Please forgive me if I'm beating a dead horse (I think some of us - myself included - are just trying to take the easier way out if it'll only work):
- Not sure what is meant by "won't set your Home and other items to that user's account for graphical apps." You mean setting permissions correctly?
- But in any event, it may be moot: Remember, we're not talking about actually running a backup from a sudo-launched SD!; we're only so launching SD! to set-up the *schedule*, then quitting, and overnight letting the schedule run the backup as root while the login window is up with no accounts open. Will solely setting the schedule under SD! launched via sudo work?
Thanks! (When we get all this ironed-out, maybe it could go in the official FAQ for server administrators.)

dnanian 01-30-2008 11:00 AM

No, I don't think it will, as I said.

gmachen 02-06-2008 10:10 AM

Dave Nanian obviously is preoccupied with this week's stellar release of SD! 2.5, yet to his credit still finds time to work the forums as best he can, bless his heart! Although he understandably doesn't have time for extended technical tomes on the complexities of Unix.

So I'm wondering whether there are any other Unix experts out there who can explain the - what to me - are very surprising putative differences between doing things in sudo as opposed to formally being logged-in as root, which arise from the security needs by network administrators to clone Mac OS X Server drives while logged-out.

I'm academically curious as to why:

- If the SD! scheduling (only!) is done under sudo while logged-in to an admin account, instead of while logged-in to the root account, it "won't set your Home and other items to that user's account for graphical apps." Does this mean it won't set permissions correctly? I really don't understand: What difference does it make what account the clone is done from if SD! is making, well, a clone, after all? I would think that all account assignment settings already had been made when things originally were installed. What am I missing?

I'm really surprised by this! When I launch other apps under sudo, they seem to think & act like they're in the root account:
- Such apps' plist preferences go into the root account's Library/Preferences folder.
- With Finder launched as root, moving something to the Trash goes to the root account's Trash folder.
- Etc., etc. I trust you get the idea.

I just need to understand the rationale behind some of this Unix stuff, even if I haven't been through the some seven years experience I'm told it takes to really get a handle on Unix. I'd like to think that our utilities' GUI shells on top of Unix put the power of Unix also in the hands of the slightly less technically sophisticated.

Thanks!

dnanian 02-06-2008 12:44 PM

If that's the case, then it might work (as I said, which is why I don't "think" it'll work). It's worth a try: it's just not something I've tested, since this general configuration, which it might work (run as root), isn't something we encourage...


All times are GMT -4. The time now is 06:06 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.