FR: Copying Logs

[ernstcs]

Hello,

Because I'm entirely lazy and dependent upon JAMF to do everything for me
(thank you), I had an idea for troubleshooting.

What is one of the first things you SHOULD do when troubleshooting a
problem or an install on a computer? Look at the logs on the computer
right?

Well, that's not always convenient. I could SSH in, I could Remote Desktop
in, or I could actually go to the machine (meh)...

Another option, I could SCP the files to my machine over SSH, but I can
never remember the syntax because I don't do it often enough. Well, I
can't remember a lot of things, but that's beside the point...

So, why not add something into Casper Remote, another tab perhaps called
Get Logs or Copy Logs. You would select the machine, go to the Logs tab
and select the more common logs from a checkbox list to have copied over.

- system.log
- jamf.log
etc.

Remote would perform the commands for SCP since it is aware of what the
remote computer's SSH credentials are, the IP address, and place the files
on my desktop named <remote_machine_name>_jamf.log, etc.

I dunno if many people would use it, just a random idea that came into my
head the other night.

Thoughts? Comments?

Thanks,

Craig E

[#2]

Here's how I would design things...

First, some definitions:

Package - A pkg/mpkg/dmg/whatever along with its associated metadata. Packages also keep track of where they've been installed, and require explicit steps to install again without uninstalling.

Task - Any action that a Policy can perform; Tasks are the building blocks of Policies.

Policy - An ordered group of Tasks, possibly including basic logical operations to decide which Tasks to run. A Policy can contain any number of Tasks, and can contain the same Task repeated multiple times. A Policy should also be able to include a separate list of Tasks for undoing its effects. Note that because a Policy can also be used as a Task, it cannot directly have a scope, trigger, time limit, or other such information.

Job - A Policy combined with scope, trigger, time limit, and other such information. A Job executes when a Machine in its scope encounters one of its triggers, within the limits specified.

Machine - A Mac (or PC) with an associated serial number and a unique identifier (UUID) automatically generated at recon time. Machines are indexed only by this identifier - not by any hardware information. Note that wiping a hard drive removes that identifier, so that a new one must be generated. This is intentional.

Senior Admin - The architects and/or maintainers of the JSS. Senior Admins are experts in the specific configuration of that particular JSS. Senior Admins build Packages, Policies, and sometimes make new custom Tasks. Senior Admins use all the tools of the Casper Suite to do their job.

Junior Admin - Junior Admins deal with day-to-day operations, such as imaging, remote support, running Policies, etc. Junior Admins use Casper Imaging, Casper Remote, and Recon.

User - Users don't know anything about the JSS, nor do they want to. They just want things to work. Users will occasionally use Self Service.

Note that there are at least three distinct audiences for the (full) Casper Suite. The design of the Suite's components needs to reflect that.

Imaging:

Imaging is little more than running a set of Tasks with a target other than / . This correlation should be made explicit; Instead of configurations, imaging should use ordinary Policies, with Tasks specifically suited for imaging (erasing the target, for instance).

Recon:

Recon (via app, jamf, Task, or otherwise) should first check for an existing UUID on the target. If it has none, one should be generated. All forms of recon should provide the option to copy the existing JSS data from another Machine in the database (defaulting to the Machine with the same serial number as the target), as well as the option to not copy policy log data. There should also be an option to erase the old entry once the copy is complete. These options would not be available if the target already has a UUID; in that case, it should only collect inventory data and send it to the JSS.

Remote:

Remote should offer the ability to build a Policy to run, or to run an existing Policy that the Senior Admin has created. If a Senior Admin uses Remote to build a Policy, there should be an easy way to automatically save that Policy in the JSS for future use.

Self Service:

When a User runs Self Service, the User is able to trigger any Self Service Jobs whose restrictions are satisfied. This will require analyzing the logical operations within the Job's Policy (which will usually deem the Policy as unavailable if the Package is already installed, or if the Package's contents were found to be installed by some other means).

In addition, some general usability enhancements would be helpful:
Nested categories and groups throughout the JSS
Policy templates, and a way of creating one's own (and installing and using templates provided by others)
Ability to logically (if not actually) merge multiple packages into one
Ability to run policies, get managed updates, etc. without ever being on the Intranet
* Ability to hide irrelevant Policies (imaging Policies for Casper Remote, for example) by flagging them as visible or not for those applications (possibly allowing them to hidden on a per-Admin basis as well)

Thoughts?

[#3]

I'd use GeekTool and pimp out your d

Sent from my iPhone

[#4]

Sorry.... Butterfingers on the iPhone.

I'd use GeekTool. You can pimp out your desktop with active Geeklets of terminal commands to any machine and really get StarTrek. Would look sweeeeeeeet on a 30" or flat screen TV

I actually use this on all my 501 accounts so I get a heads up display of system log
Jamf log
uptime
Host file
Machine name
ntp.conf
Ethernet stats
And a few others can't think of.

All set to a black background. Gonna wrap them up in LCARS swooshes soon :P

-pat
Sent from my iPhone

[jarednichols]

I crafted a shell script to submit logs. Tier 2 can either run it with
Casper Remote, or the user can go into Self Service and run it. The
script is attached.

On the server-side, I created a share that was write only for guest
("dropbox") and the appropriate support people have read access to it so
they can copy the logs down. We were able to get away with guest access
because OS X lets you do this on a per-share basis. On Windows (and maybe
this is different on 2008 R2) if you enable guest access it applies to all
shares on the box.

Have fun!

j
-- Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

[#6]

I've fixed up your script for more general use:

It now pulls info from what Casper provides (in $1, $2, and $3), if available
Defaults are as before, but you can now specify the protocol, server, share, and auth info by passing them to the script
Added quotes to prevent potential issues (you never know...<http://xkcd.com/327/>)
List of log folders is now separate from the body of the code, for easier modification
Changed /var/log to /private/var/log
The script now fails if the share couldn't be mounted
* Added the current time to the filename; otherwise the script would fail if run twice on the same computer on the same day, if the share is write-only - Note that colons in the filename will show up as slashes in the Finder

I haven't tested this script, but it should work.

[Bukira]

Cheers i was editing some of this myself and testing, ill test urs

Criss Myers
Senior IT Analyst (Mac Services)
iPhone / iPad Developer
Apple Certified Technical Coordinator v10.5
LIS Development Team
Adelphi Building AB28
University of Central Lancashire
Preston PR1 2HE
Ex 5054
01772 895054

[jarednichols]

I smell resource kit :)

j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

[#9]

It needs more comments first...

What does the Resource Kit smell like?

[ernstcs]

Nick

[sean]

Almost always want to look at the logs for the last 15 mins or so, which wont be available unless you run a Remote task, for example, to grab them.

So what is the difference of setting up templates in Remote Desktop to do unix commands, as to having to launch Casper Remote and send a command, etc.

I'd stick with Unix templates in ARD, which is pretty lazy (only one click to get it to re-run) or lazier still, as someone suggested, get the user to use Self Service and have it run a script which sends you the logs.

I guess you could run a script to run every 15 to grab the logs, but I personally wouldn't.

Sean

[sean]

Almost always want to look at the logs for the last 15 mins or so, which wont be available unless you run a Remote task, for example, to grab them.

So what is the difference of setting up templates in Remote Desktop to do unix commands, as to having to launch Casper Remote and send a command, etc.

I'd stick with Unix templates in ARD, which is pretty lazy (only one click to get it to re-run) or lazier still, as someone suggested, get the user to use Self Service and have it run a script which sends you the logs.

I guess you could run a script to run every 15 to grab the logs, but I personally wouldn't.

Sean

[ernstcs]

You're making an assumption that I use ARD, when you say Remote Desktop.

I'm not trying to say this in a punchy fashion here with my statements so
if I express something poorly here my apologies.

I'm somewhat a Casper Suite Purest, if there is such a thing. I try to
avoid doing things outside of the Casper Suite when ever possible. Many of
my suggestions are made simply to get them into the one tool I'd like to
keep using so I only have to deal with one simple tool. I don't use ARD,
and I don't use Workgroup Manageer. Casper Suite with AD bindings.

Scripting things as people suggested is great, and I know that can be
done. The other cool utilities out there mentioned are great. However, as
soon as I branch out of the Suite then continuation of support can be more
difficult the more custom I get outside of my supported management system.

Craig E

[jarednichols]

Victory?

j
-- Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

[#15]

Which is why we're smelling the Resource Kit for this script.

It becomes a nightmare to administer a system involving several different management suites, all working against each other. The best solution is to get one suite to do as much as possible. I'm not sure if Casper is that one, but it seems to be closer than any others I've seen. Its interfaces are sorely lacking, though...

[tlarkin]

Well.....

I could whip up a function in a script that grabs all logs and then puts them in a nice little dmg file via hdutil and then uploads them to a fileshare via scp or ditto or rsync, etc. Then you can just have the Casper stuff run it. When a policy in Casper runs a few things always happen.

1) casper authenticates to the casper share on the distribution point and mounts the share 2) Casper has read/write access to that share 3) You can easily create a folder in your Casper Share and have to copy files to it.

The other option would be to feature request that Jamf put in an option to inventory system logs off of client machines. Maybe grab the last 150 lines every time it checks in? I can see a lot of issues with this though as if you have 1000s of clients checking in and copying logs it can eat up HD space a lot faster than you think.

Perhaps if there was an option to flag a client machine in "debug mode" and it would copy the logs to that machine's inventory.

[ernstcs]

I'm wondering if you care to expand on this?

[#18]

I'm sure everyone on this list is familiar with the usability issues in Casper Remote, so I won't bother talking about that.

The presumption that anyone who does any administration is an expert in the existing configuration seems evident to me. I think that covers many of the usability issues I've seen. Features like policy encapsulation, nested grouping in many places, and various others are clearly lacking.

I'll follow up with more details after I get lunch.

[#19]

I actually requested this feature last year ­ sounds like it would be a
really useful feature for some of us. Sometimes we've had issues with a
machine, but due to time constraints (it's very hard to take one of our
machines out of production for any length of time) we often just re-image
and move on. If logs aren't gathered, debugging that issue may be 'gone with
the wind'.

I would love to have seen the submitlogs.sh script...but it was blocked from
my email. (Come on, now...Mac or no Mac, sending around .sh files as an
attachment?? Any corporate mail server that DIDN'T remove that should be
wiped!) How about re-sending as a zip file, or at least in the body of a
message?

Christopher Kemp
CNN Central Engineering

[ernstcs]

Cuz our server would strip it out of the zip, too. =D

But yeah, rename it .txt or put it in the body, yo!

Craig E

[#21]

Ah, that had not occurred to me. I wondered why you used a .zip. Sorry about that. Here it is, but beware unexpected line breaks:

#!/bin/sh

################################################################################################
##### Filename: submitlogs.sh #####
##### Author: Jared F. Nichols #####
##### Purpose: Submit logs to the JSS #####
################################################################################################

if [ "$1" != "afp" && "$1" != "smb" ] # Casper wouldn't use either of these as $1
then
# Pull the info from $1, $2, and $3, then shift params
fsroot=${1:-/}
hostname=${2:-jamf getComputerName | sed -e 's/<computer_name>//' -e 's/</computer_name>//'}
username=${3:-ls -l /dev/console | cut -d " " -f 4}
shift 3
else
fsroot=/
hostname=jamf getComputerName | sed -e 's/<computer_name>//' -e 's/</computer_name>//'
username=ls -l /dev/console | cut -d " " -f 4
fi

if [ "$fsroot" == "/" ]
then
userLogs='"$fsroot/Users/$username/Library/Logs"'
else # Console user doesn't exist in $fsroot
userLogs=''
fi

protocol=${1:-afp}
server=${2:-LLCasper01}
shareName=${3:-ClientLogs}
shareUsername=${4:-guest}

# ** WARNING **
# This password will be visible in the logs and the process list!
sharePassword=$5

logFolders='"$fsroot/private/var/log" "$fsroot/Library/Logs"'
dateFormat=date +"%Y-%m-%d %T"
filename="$dateFormat-$hostname.zip"

jamf mount -server "$server" -share "$shareName" -type "$protocol" -username "$shareUsername" -password "$sharePassword" || exit 1
zip -r "/Volumes/$shareName/$filename" $logFolders $userLogs # $logFolders and $userLogs are intentionally unquoted here
umount -f "/Volumes/$shareName"

exit 0

[tlarkin]

If you are using kerberos you could pass a user with access with no password as long as they had a valid ticket, or output the whole script to /dev/null. Also, if any of you have used the Apple Enterprise support where they have you run EDC on your systems, it grabs all logs and tosses them in a folder and then uses the hdutil under the hood to compress them into a DMG file. The hdutil can compress whole folders, so instead of using zip you could also use that to compress it to copy it.

Just a thought

[jarednichols]

Woah slow down there folks…

That script is based upon my original script. My script wrote the log zip directly to a guest drop box. I'd never ever ever ever use a visible password to a share. Please make sure you modify to indicate it was based on a script I had. I don't want any sort of attribution to a poor security practice like this.

Thanks.

j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

[#24]

My apologies. I simply left the script's header alone; I did not intend to indicate that you wrote this version.