Krypted » Mac OS X Server

Making Every User an Admin

admin — Wed, 28 Jul 2010 02:00:14 +0000

If you deploy a large number of computers to users who are somewhat likely to play practical jokes on each other then you will run into some interesting issues. If you are deploying one computer to every user and you want each user to be an administrator of their computer then you might be tempted to allow all users to be administrators of all computers. If you do then prepare for an infinite number of sometimes amusing practical jokes. But really, being proactive about this brings up an interesting point: how do you deploy a computer and make only the user who you want to be an administrator an administrator.

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:

Copyright © 2008
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
)

Customizing the Wiki Banner

admin — Tue, 20 Jul 2010 22:52:50 +0000

One of the best features of Mac OS X Server is the built-in blog and wiki services. While it is not the right solution for every type of environment, it is a very good medium for internally hosted user generated content. Especially if you are using Active Directory or Open Directory. One of the most common requests I get when setting up a blog and wiki server is to customize the portal so that it is branded to the organization that it’s being set up for. One of the easiest ways to do this is to just edit (or more likely replace) the banner-bg.png file located in /usr/share/collaboration/css/serverhome_static/img directory.

There are other items here that can easily be replaced with items of the same size; however, the most impactful is the huge banner sitting atop the screen when users visit the page. Your new banner-bg.png file should usually be 990 by 197 pixels and be trimmed down to be as small a file as possible. I have to admit that I’m not great at Photoshop, so I often cheat a little and use Art Text, by BeLight Software. In order to make this easier for others who might do exactly this, here is a template (forgive my utter lack of any graphic design skills whatsoever) that you can use.

Happy Customizations (and feel free to submit any images/links that you’re proud of and I’ll be happy to post/link to them)!Similar Articles:

DeployStudio: Rename a Volume with Host Name

admin — Sat, 12 Jun 2010 18:40:34 +0000

DeployStudio has the ability to rename volumes as part of a standard workflow. These are typically set to something like “Macintosh HD” (the default) or “Computer Lab” or something like that. But what if you wanted to name the volume something unique to a given computer, which makes it easier to keep track with what you are doing across a number of servers? You could create a workflow for each computer and change the hard drive name for each to something unique; but that would be tedious and pollute your list of workflows, likely resulting in accidentally running the wrong workflow at times. Instead, you could look at a really simple script in most cases (according to how complicated your logic for assigning names would be).

To rename a volume, you can use the diskutil command along with the rename option. You would then list the existing name followed by the new name that you’d like that volume to have. In the case of DeployStudio the initial name of your boot volume might be “Macintosh HD” and to change the name to something like “Computer Lab” you would then use a command like:

diskutil rename Macintosh\ HD Computer\ Lab

It might then be logical to use a host name to rename a computer. Therefore, we could replace Computer\ Lab with the hostname command like so:

diskutil rename Macintosh\ HD `hostname`

However, this ends up showing the fully qualified name. Therefore, we could replace hostname with an scutil query for the ComputerName:

diskutil rename Macintosh\ HD `scutil –get ComputerName`

This would result in the name without all the .local, etc. But if you ran this as part of a DeployStudio workflow, you would end up calling the hard drive for all of your machines localhost. This is because the hostname or ComputerName will be queried from the DeployStudio set that you are booted to for running the DeployStudio Runtime. Luckily, DeployStudio has a number of variables that it can use in scripts. One of them is DS_HOSTNAME, which pulls the ComputerName being applied to the system at imaging. This means that if we were to rename the hard drive of the computer from Macintosh HD to the DS_HOSTNAME, you could use the following script:

diskutil rename /Volumes/Macintosh\ HD $DS_HOSTNAME

Now, one might think to oneself, couldn’t I just put $DS_HOSTNAME in the field for renaming the hard drive (part of a workflow). I tried it a number of different ways and couldn’t get it to work (in parenthesis, quoted out different kinds of ways, in different types of brackets and combinations of the above). If anyone knows of a way to use a variable in a GUI field within DeployStudio, let me know (I am guessing it can be done).Similar Articles:

MacSysAdmin

admin — Fri, 11 Jun 2010 20:24:41 +0000

MacSysAdmin will again be held in Gothenburg, Sweden. The dates for MacSysAdmin (and most of the speakers) have been announced. The conference will be held from September 29th through October 1st at the Folkets Hus.

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:

Stupid Podcast Producer Tricks

admin — Thu, 10 Jun 2010 15:00:08 +0000

The document handler in Podcast Producer has been exposed to the command line in the form of a tool called document2images (located in the /usr/libexec/podcastproducer directory), which takes a pdf and converts it into a set of tiff files. In its most basic iteration the documents2images tool simply inputs a document and then outputs a couple of tiff files per page of that document. 15 pages will typically net you 30 tiffs and an xml output (not that you can put Humpty Dumpty back together again very easily).

When you use document2images you will need to specify the pdf using the –document option, the xml file to output using the –xml option and the directory to drop your images into using the –imagespath option. To use an example of this command, if I wanted to convert a pdf called /Users/cedge/Desktop/test.pdf into images in the /Users/cedge/Desktop/tiffs directory and drop the XML file into /Users/cedge/Desktop I would use the following command:

/usr/libexec/podcastproducer/document2images –document /Users/cedge/Desktop/test.pdf –xml /Users/cedge/Desktop/test.xml –imagespath /Users/cedge/Desktop/test

It’s worth note that the user invoking the command will need access to write to the directory that you’re dropping your images into as well as the directory that the xml file will be written to (and of course, to read the pdf).Similar Articles:

BRU Primer -> Advanced

admin — Wed, 09 Jun 2010 15:00:43 +0000

In BRU 2, you have 3 tools to use. These include:

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:

Debug Logging iCal

admin — Sun, 06 Jun 2010 14:00:51 +0000

One of the tools in the iCal -> iCal Server troubleshooting toolbelt is to debut log HTTP connections. You can capture packets for port 8008 using tcpdump. In the following command, we’ll capture the packets over interface en0 for tcp port 8008 to a file called iCal.pcap:

tcpdump -w iCal.pcap -i en0 tcp port 8008

We’ll then attempt to create a calendar entry in iCal or simply log into the server through iCal. CalDAV traffic will occur and then you can stop the tcpdump. In order to then read the tcpdump:

tcpdump -nnr iCal.pcap

Another option that can help to correlate traffic you see in the pcap from tcpdump is to enable debug logging of HTTP traffic in iCal. To do so, we’ll use the defaults command to write a TRUE value into the LogHTTPActivity key of the com.apple.iCal defaults domain:

defaults write com.apple.iCal LogHTTPActivity -boolean TRUE

Given the output of LogHTTPActivity and tcpdump to iCal.pcap you will in most cases triangulate the source of many of the problems that you encounter in iCal Server. Whether iCal cannot traverse to a given directory with CalDAV data, iCal cannot connect to the server or there is another form of connectivity issue, much of the troubleshooting will start with looking at the traffic over port 8008.Similar Articles:

Monitoring/Restarting Retrospect

admin — Fri, 04 Jun 2010 14:00:10 +0000

As of version 8, Retrospect uses port 22024 when the Retrospect Console needs to communicate with the engine. It just so happens that this can become unresponsive when the engine itself decides to stop working. Therefore, if you’re using Retrospect 8, you can run a port scan against port 22024 ( i.e. stroke 22024 22024 ) and then restart the engine if it goes unresponsive. To restart the engine, simply unload and then load com.retrospect.launchd.retroengine. For example:

/bin/launchctl unload /Library/LaunchDaemons/com.retrospect.launchd.retroengine.plist; /bin/launchctl load /Library/LaunchDaemons/com.retrospect.launchd.retroengine.plist

I have found that if you alter the nice value that the engine crashes less (not that I’m saying that it crashes a lot or is buggy btw, just seen it in a few cases now). To do so, change the nice value in /Library/LaunchDaemons/com.retrospect.launchd.retroengine.plist from the default (0) to -10 (or -20 even).

Historically, there have been intermittent issues with the client software running. To determine if it’s running or stopped from within the host that the client is running on you can use the following (for versions 6 and below):

ps -cx | grep retroclient

Or you can use the following for version 8:

ps -cx | grep pitond

Or you can port scan port 497 for the client:

stroke 497 497Similar Articles:

iCal Server en Masse

admin — Fri, 28 May 2010 22:31:12 +0000

Deploying iCal Server across a large number of systems at first seems somewhat time consuming. But there are a few options to make things easier than manually touching each system, or trying to script the setup process.

When you first open iCal, it will allow you to do an Automatic setup using your email account and password. The server that it will setup this information for is based on a service record (SRV) for CalDAV being found in DNS. For automatic deployment of an iCal Server you can build a service record in DNS that will point to the server. The record should have the following settings (you can leave the Service Name empty):
Service Type: _caldav.tcp (non-ssl)
Host: the name of your server (ie – server.mycompany.com)
Port: 8008

The port setting can change if you’ve manually set a new port for your server. To verify the port number use this command:
sudo serveradmin settings calendar:HTTPPort

Similar Articles:

None Found

One More Character In Serials

admin — Thu, 13 May 2010 14:00:57 +0000

Yesterday I showed a way to get the serial number from a Mac OS X machine. However, as a couple of people pointed out, Apple will soon be adding another character to the serial number. This means that rather than use cut I should have used awk to allow for either serial number length. To grab the serial this way:

ioreg -l | grep IOPlatformSerialNumber | awk ‘{print $4}’

Or without the quotes:

ioreg -l | grep IOPlatformSerialNumber | awk ‘{print $4}’ | sed ’s/”//g’

Similar Articles: