In a large deployment of Mac OS X, you are going to likely have a map somewhere between what user has each computer. You may even go so far as to name the computers the same name that you name the user associated with the computer. If you do this, then you have a pretty straight-forward task ahead of you. Basically, you’ll add the user who you are handing the computer to an administrator by adding them to the admin group. In order to do so, can check the “Allow user to administer this computer” as you can see in the following figure.
If you have a sizable deployment you’ll want to automate this task rather than log in as each user and set the setting. You can automate the task using the dscl command along with the append verb. For example to place the user cedge into the admin group:

sudo dscl . append /Groups/admin GroupMembership cedge

That works as a one-off operation but not in bulk. If your computer name is the same as the user who will be using the system you can then use the scutil command and “–get” the ComputerName:

scutil –get ComputerName

NOTE: The –get options in this article are two hyphens rather than one, WordPress just merges them for some reason…

You can then use this as the variable to use for augmenting the GroupMembership for admin:

sudo dscl . append /Groups/admin GroupMembership `scutil —get ComputerName`

Pop that into a post-flight package and you’ve got yourself a solution where you make the primary user of a system the admin of the local box and then make the subsequent users standard accounts. If your ComputerName doesn’t match your user name then all is not lost. One way to grab what admin user you’d like for each host would be to populate something on the client with that information. Another would be to put it in a csv and read the line for the csv that is associated to the computer in to obtain it. If you populate something on the client it could be the Text1 field from Apple Remote Desktop. This can be done using the Remote Management option in the Sharing System Preference, clicking on Computer Settings and then typing the data into the Info 1: field.

To insert the information at image time (or at least programmatically), you could use defaults to write it into com.apple.RemoteDesktop.plist, located in /Library/Preferences:

defaults write /Library/Preferences/com.apple.RemoteDesktop Text1 “cedge”

To then read that variable:

defaults read /Library/Preferences/com.apple.RemoteDesktop Text1

The command to set the admin user based on the Text1 field would then be:

sudo dscl . append /Groups/admin GroupMembership `defaults read /Library/Preferences/com.apple.RemoteDesktop Text1`

There are probably about as many other ways to go about this as there are Mac OS X mass deployments. For example, instead of inserting data into Text1 from a defaults command, you could use kickstart with the -computerinfo option to write data into -set1 -1 or something like that (which is likely safer than defaults, albeit more difficult if you decide to do it to your non-booted volume). But hopefully these options, somewhere down the road, will help someone (after all, that’s why we post this kind of thing, right?!?!).Similar Articles:

• Create Groups Using dscl
• Mac OS X: Fast User Switching
• Mac OS X: Fun with scutil
• Programatic Screen Sharing
• Apple Remote Desktop: Setting up a Task Server

I am honored to again be a speaker and will be there throughout the conference, which includes sessions from a number of Mac gurus, including Arek Dreyer, Andrina Kelly, Alan Gordon, Karl Kuehn and Duncan McCracken.

Click here to sign up and hope to see you there!Similar Articles:

• Speaking at MacSysAdmin 2009 in Sweden
• MacSysAdmin Videos
• Slides from MacSysAdmin Talk on Enterprise Backup

• BRU Server Agent Config (UB) – A tool used to install the agent, which needs to be located on each machine that will be backed up (including the server if it has any data to back up)
• BRU Server Config (UB) – Used to configure the server daemon, backup server configurations and set passwords to communicate with the server. Also used to set licensing information and perform scans for new tape drives and libraries.
• BRU Server Console (UB) – Used to configure backup jobs, schedules, etc.

To get started, open the BRU Server Config application from the components that come with your software (or that you downloaded from the BRU website). First you will be asked to provide an administrative password to BRU. Provide the password and then click on Save.

Next, the server components will be copied to /usr/local/bru-server. The system will also perform a hardware scan of your server, looking for tape drives and libraries (you can always rerun this process later if need be).

Once the processes are complete the BRU Server Configuration Tool will open and you can configure the server. To do so, first click Start to start the daemon. If you need to restart it at a later date you can simply click on the Stop or Restart buttons here. Then, if like most, you would like for the server to start at boot, check the box for Server daemon starts at boot. Here, you can also use the Backup and Restore buttons to backup and restore server configurations or the Modify button to enter a new password for the server.

You can also perform most of these options from the command line using the server command located in /usr/local/bru-server. For example, to stop the server, you would use the –kill option:

/usr/local/bru-server/server –kill

To then start the server, run it with no arguments:

/usr/local/bru-server/server

Or to set the password, you would use (go figure) the –password option:

/usr/local/bru-server/server –password

You can also perform some options not exposed in the Configuration Tool GUI, such as running it on a custom port using the –port option followed by the port number:

/usr/local/bru-server/server –port=8090

Finally, you can check the version and license information using the –version and –license options respectively.

Once you are satisfied with your configuration of the server component, you will then close the tool and move on to installing the Agent(s). Each machine that will get backed up will need an agent installed. Configure the options for the BRU Agent using the BRU Server Agent Config application. Simply open the application from your installer. On first open, the agent will copy /usr/local/bru-server to your machine (if you installed the server it will just copy the agent portions of BRU), which will contain the agent. You will also then see a b icon in the menu bar. Click on the b icon in the menu bar and then click on Agent Configuration to bring up a screen similar to the following.

Here, click on the Start button to configure the agent. You will typically want the agent to start automatically when you install a system, so click on the check box for Agent daemon starts automatically. You will then need to provide a server that the agent can communicate with. To do so, click on the plus sign (+) on the screen and then provide the server that the agent can communicate with and the credentials to do so. Once complete, you will then be able to see the client system in the Server Console.

You can also configure it from the command line, fairly easily. To do so, run the agent, located in /usr/local/bru-server, along with the –config option:

/usr/local/bru-server/agent –config

The BRU Server Agent Configuration will then enter into the interactive mode and you will see any BRU Server Console’s that the agent is configured to communicate with. Here, type N and then you will be prompted for the hostname of your BRU Server. Here, provide the  name or an IP address for the server and then hit the enter key. When prompted, provide a password to enter into the Console. The server will then be assigned a unique number. Entering that at the interactive prompt will then remove the server again. Once the agent has been started, it can be stopped by running the agent command with the –kill option:

/usr/local/bru-server –kill

Note: For Windows, the configuration command line tool is located in C:\Program Files\BRU Server Agent Configuration.

Now that you have configured the agent and the server, it’s time to actually setup jobs and schedules. To get started, open the BRU Server Console application. The console components will then be copied into /usr/local/bru-server.

Click on OK and then the authenticate to the server.

Once you have logged in, you will see the console. If the installation of the agents went properly, you should see any that you have installed as well.

Disk-to-Disk backups in BRU are mostly considered a staging area, where data is stored while waiting to be shuttled to tape. To set the staging area, click on the BRU Server Console menu and then click on Preferences…

In the Stage Path field, provide a path that the stage files will be stored in. You can also set the maximum age of the staging data and the number of jobs to be stored in the history. When you’re satisfied with your settings, click on the Save button.

Back at the Console screen, you will click on the plus sign (+) to add a new backup job, which will bring up the screen you see here.

The backup job will include the following options:

• Job name: A name for the job.
• Destination: Where the backup will be written to. You can use Stage Disk or choose a tape drive/library.
• Backup Type: Your first job will need to be a full, subsequent jobs can be incremental or differential, which will require you to set a full job that you have created as the “Base Job”. An incremental will backup files that have been altered since the last incremental or full backup. A differential will backup all files altered since the last full, even if they were already backed up. Differentials will lead to faster restore times as you near the end of a backup cycle; however, they will usually take up considerably more space.
• Base Job: The full backup job to base a differential or incremental backup job on.
• Compression: Whether or not the software will attempt to compress data. Enabling compression causes slower backups, but takes up less space.
• Email: An address to send backup reports to for the given job.
• Verify Backup: Performs a scan of backed up files to ensure they match the source. This will take longer than if you do not enable it but provides peace of mind/assurance/etc.
• Eject Tape after job completes: Only used if you are using tape, usually not used if you are using tape libraries.
• Enable archive encryption: Encrypts archives

Once you have configured a job as you see fit, click on OK and you will be taken back to the BRU Server Console screen. For each job you will still need to configure a schedule for the job as well as what source directories/files to be backed up. To set the schedule, click on the job name to be scheduled and then click on the Schedule… button. At the Job Scheduler screen, set the frequency and starting times that your job should run at and then click on the Save button.

You will then need to configure the source directories for your backups. Back at the Console screen, click on the name of the job and then click on each directory to be backed up. Clicking on a directory will cycle through color codes. The colors indicate whether or not the directory will be backed up:

• yellow indicates that part of a directory will be backed up
• green indicates the entire directory will be backed up
• red indicates that a directory will explicitly be skipped

When you are satisfied with your backup job, click Save. You will then configure an incremental or differential job for each base job and finally a job that is specifically for upstaging data to tape, or completing the disk-to-disk-to-tape sequence. When you are finished configuring each of your jobs you can run them manually to test by clicking on the Run Now while the job is selected from the console. When running, you can monitor each job using the Tools icon in the side bar and then the Job Monitor option in the Tools drop-down menu. To stop a job that is running, you can click on the Kill command here.

You can also run jobs from the command line, using the backup option for the bru-server.cmd command located in /usr/local/bru-server. The command can be run using the -j option (name of job), followed by the name of the job to be run, followed by the -t option (type of job), followed by the type of job being run (ie – Full, Incremental or Differental), followed by -Z (enable compression) and -v (enable verification), followed by the paths (starting with server names) to be backed up in brackets. For example, to run our test job:

backup -j “test” -t “Full” -Z -v ["/krypted//Volumes/Installers"]

This allows you to somewhat seamlessly integrate the backup of files that are archived with Final Cut Server, by calling up the backup command as a post-flight action for any automations kicked off by Final Cut Server. You can also backup data using the bru-server.cmd command in /usr/local/bru-server. You can then restore files that are backed up using the bru-server.cmd command’s restore option. In order to use the restore option, you’ll need to know which archive the file is stored in. In order to find that you will also need to script the search option (search for the appropriate file and then craft your restore to pull data back to the restore path for fcsvr_client using the correct archive that the file is stored on). To search through the archives for the appropriate file:

search “my file.mov”

You can also provide archives as part of the search, but we likely wouldn’t be searching here if we knew which ones to use.

Note: The BRU commands are based on python. When the python environment on a machine has been customized the results for BRU can be unexpected.Similar Articles:

• Backup Exec for Mac OS X
• Cage Match: Retrospect vs. BRU
• Archive & Restore Assets with fcsvr_client
• Mac OS X: Trusted Binding
• Howto Install awstats on OS X

Google Maps is one of my favorite parts of the web. Before I book a hotel room I usually check out the area from a few different angles. In part, this is made possible by the Google street view cars. These little cars zip around the globe taking images of the front of our homes, out potential hotels and even catch people doing things they shouldn’t.

But those same cars were also war driving. Really, I’m sure they were mostly collecting SSID and MAC addresses to allow non-GPS enabled computers to be physically aware of their location based on approximate wireless connections. This service, included from another vendor in Mac OS X, looks up close wireless networks and based on unique values from those networks can set your time zone. There are a myriad of other uses with mapping out wireless access point locations, but other than winning competitions at DefCon, that’s the most popular.

Those little cars that Google sends around were also capturing information that they weren’t intended to capture: live network traffic from networks lacking encryption. Not much, as the wireless equipment in those cars changes channels a few times a second… Sniffing wireless traffic is something that has been possible for a long time. But few could have sniffed as much traffic as Google given our lack of fleets of automobiles running around the world doing so.

But Google did the right thing. It was uncovered, they posted it to their blog and sought out a third party to help them to review and then dump the data. So good going Google. Thanks for not being evil, and please keep those cars running around the world and helping to make the web a more interesting place to visit. Oh and if you’re not securing your wireless networks, take this as yet another reason to do so…Similar Articles:

None Found

Or for ACMA (the Final Cut below could be swapped out with Support Essentials, Directory Services or Deployment):
Similar Articles:

• Apple's New Certification Track
• Adding DHCP Options in Mac OS X Server
• Snow Leopard & Malware
• Windows 7 in October
• DeployStudio: Creating a New Master Image

shutdown -h now

You can also restart a system by running the shutdown command with a -r option and the same now as before, as follows:

shutdown -r now

You can also replace the now with a specific time and date to set the system to shut down and/or restart in the future. But these don’t log the system out and leave you at a login window without first actually rebooting a computer we might not be ready to reboot (or we might not want to reboot/shut down). One way to get close is to use the options we referenced yesterday to invoke fast user switching. But it’s one of those things that there’s no real framework for at this time. Again, there is close. You can use AppleScript, but it’s going to ask the user to log out

tell application “System Events” to log out

You can then send this through the shell using osascript:

osascript ‘tell application “System Events” to log out’

Once the screen comes up you could send a subsequent command to click on the Log Out button. However, this can be cancelled by a screen that can’t be closed or a file that needs to be saved (which is by design given that you don’t typically want to risk loosing work) or because an application is unresponsive. We could quit all the open applications using a loop, such as the one I use in the hide all apps application, but then we would need to determine logic on how to answer certain questions that could come up. It was suggested to use killall with the -u option to kill all processes for our current user:

killall -u cedge

But that introduced a little loginwindow instability. So maybe we could just kill loginwindow for the user. To do so we first need to get the pid for loginwindow:

ps -Axjc | grep loginwindow | cut -c 13-16

Once we have that, we can feed it to kill:

kill -9 `ps -Axjc | grep loginwindow | cut -c 13-16`

Which can then be sent through AppleScript as:

tell application “Finder”

do shell script “kill -9 `ps -Axjc | grep loginwindow | cut -c 13-16`“

end tell

Now that it can be done through bash and AppleScript you have a variety of ways to run it against a client system. It’s not as clean as I’d like (throws a few errors in the logs and seems like a hack), so perhaps there’s a better way…Similar Articles:

• Mac OS X: Invoke a Command w/ ScreenSaver
• Scripting Fast User Switching
• Login & Logout Hooks
• Shell to Clipboard & Back Again
• Scripting a Battery Sanity Check

BREAKING NEWS – New York City – MacPhoneHome finds another stolen computer!

Late on a recent Sunday night, a Columbia University student
was crossing Morningside Park returning to the Columbia University
campus.

He was accosted by four knife wielding thugs who beat him and robbed his
MacBook Pro laptop, iPhone and wallet.

The student advised Columbia University security personnel that
since his laptop was partitioned with both a Windows and Mac Partition,
he had installed both PC PhoneHome and MacPhoneHome tracking and
recovery software on his computer which is available by contract to all
Columbia University students, faculty and employees as a free download.

Columbia University security personnel immediately notified Brigadoon
Software, Inc.the makers of PC PhoneHome and MacPhoneHome who’s recovery
agents, most of whom are former law enforcement, sprang into action.

Messages from the stolen machine indicated the thieves were using both
partitions of the stolen computer and moving around logging onto the
internet from various locations in the NYC Metropolitan area in the
following week.

Working with NYPD Detectives, Columbia University security personnel
and local Internet Service Providers, Brigadoon’s Recovery Agents
pinpointed the exact location of the stolen laptop. NYPD Detectives
secured a search warrant and raided the location.

Result: The student’s MacBook Pro, his iPhone and wallet
were recovered. One mugger arrested and three others
have been identified and are being sought.

What are you doing to secure your computers from theft?

Checkout PC PhoneHome and MacPhoneHome at: http://www.brigadoonsoftware.com

Similar Articles:

• Lo/Jack
• iPhone Worm is Crap
• On the Road: Sprint SmartView
• Mac OS X: Check Point FDE
• MinneSec

I’ve liked the PGP brand since watching Zimmerman fight to keep PGP going in the early 1990s, when PGP met the standards of a non-exportable weapon. That is, until Zimmerman published a physical book with the source code in OCR-friendly font and ended up with PGP covered under the first ammendment. All of that is such old history though. Zimmerman has been gone since 2001, after a merger and then an acquisition by Network Associates. The company then ended up getting dumped by Network Associates and refounded (with assets bought back from Network Associates) with a little VC. It’s been a weird journey to get to where they are today. I hate to watch it go away (again) as a company though. Hopefully this acquisition will go better than things went when they were part of Network Associates.

Symantec is also acquiring GuardianEdge. GuardianEdge products already integrate nicely alongside the Symantec portfolio. You can even deploy GuardianEdge with a special Altiris Connector into Altiris Notification Server, which alerts you when systems “present risk to protected information”. Overall, either PGP or GuardianEdge seem like great adds to the Symantec lineup. Both from the outside seem a bit superfluous but I have to guess someone has a great strategy for integrating the two brands into one. I look forward to watching it unfold.Similar Articles:

• Symantec Continues to Beef Up SaaS Solution Offerings
• Mac OS X: tail
• Mac OS X for Unix Geeks
• Houseport Z-Wave for Mac Finally Available!!
• Lo/Jack

HellRaiser is a RealBasic-based trojan horse that gives control of a Mac OS X system to an attacker. This can include searching through the file system and then transferring files, viewing the clipboard, sending audio, sending chats, viewing the screen, showing pictures, viewing spotlight indexes, controlling mail and rebooting (see the tabs below).

A number of products will detect the OSX/HellRTS.D. trojan horse when using the latest definition updates, including the following (which links to the HellRaiser entry for each vendor):

• Sophos
• McAfee
• Symantec
• MacScan
• Intego

HellRaiser is not widely distributed and so most users have a pretty low risk of being infected. However, be wary of files you get from untrusted sources (especially the ones called HEYI’MATROJANPLEASEDOWNLOADME from BitTorrent;) and run some form of anti-virus on your systems. It’s pretty easy to take the HellRaiser application, customize it to your liking and then distribute it (let’s just say as part of a bundle of iChat Smileys or a fake iLife download). If you find yourself infected (again, a low risk that this will happen) and don’t have any anti-virus, just kill the launchd item that’s invoking it, but first do me a favor and enable ipfw and then ipfw logging for the port that it’s attempting to connect over (by default it’s 24745). Then let me know the address… If you’re not sure whether you’ve been infected, just look for an item running that has a broken File menu (I guess it’s hard to program menus… not) and greyed out preferences. It would need to be recompiled if it was going to have a different quit menu, so you might even see Quit HellRaiser (followed by the version number).

Overall, this isn’t nearly as dangerous as having an SSH server or a client/server remote screen sharing tool that you don’t know about running on your machine. If anything is dangerous it’s the idea that there’s a GUI toolkit for this type of stuff floating around for Mac OS X (and has been since 2004) and that a small 0-day (happens all the time for platforms) could turn into a mass infection fairly easily…Similar Articles:

• iWork or Trojan
• Mac OS X: New Trojan Discovered
• Mac OS X Server: Customizing Menu Items with Open Directory MCX
• Finder: I Just Can’t Quit You
• Apple Remote Desktop: Setting up a Task Server

http://www.xsanity.com/article.php/20100415165329925Similar Articles:

• Xsanity: Using Removable Media with Xsan
• Xsanity Post on fibreconfig
• Xsanity Party at MacWorld
• Customizing the Final Cut Server Webstart on Xsanity
• Installing a Vtrak for Windows