I’m hearing reports that MobileMe Calendar has come out of beta. My web interface appears to be sitting on the fence. The /beta link doesn’t work, but the /calendar link appears to load to the CalDAV-specific solution.
Does anyone else see their MobileMe calendar web client is out of beta?
Update: Yes, it’s out of beta. Here’s the FAQs.
AFP548.com has posted part 2 of their interesting guide on implementing z-push on Snow Leopard Server to fool your ActiveSync devices into thinking they’re communicating with an Exchange Server. I want to try this very badly, but limited resources prevent that at the current time.
If you’ve gotten this working and can speak about the experience, we’d love to hear from you!
AFP548.com has posted a very intriguing article on setting up the open source product z-push to implement Exchange ActiveSync on your Snow Leopard server. This provides Exchange-style push mail for your iPhone after you trick the device into thinking it’s an Exchange server.
Part 2 of the article even claims that they will provide info on how to perform remote device wipe.
I’ve not personally tried these steps yet, but perhaps I shall one day soon. Proceed with caution and if you get this working, I’d love to hear about it in the comments.
Now this enterprise stuff is getting very, very interesting…
Businesses are infatuated with calendaring. The proliferation of mobile devices has contributed to the love affair. Getting your calendars to work right and work well for you and your business can sometimes be a challenge.
One facet of calendaring is delegation. Some setups get this right, maybe get it wrong. Most of the time it’s wrong just because it’s misunderstood. Okay, yeah, I know, that’s the Exchange world. We’re not going to talk about that. We’re here to talk about OS X Server and iCal. iCal Server on Snow Leopard supports the concept of delegation. Fortunately, the iCal client on Snow Leopard also supports delegation. Apple has boiled it down to two simple permissions: read and/or write. That’s enough for most people. If you’re an all-Mac shop and no one is trying to do delegation with an iPhone, you can stop reading here.
If you are, however, a heavy user of delegation functions, you may be surprised to find the lack of delegation options in the CalDAV setup on the iPhone. Not to fear, we can solve that for you. The iPhone CalDAV client actually does support delegation with iCal server. It’s just not readily apparent.
Let’s say we’re trying to set up delegation with my manager, Joe Schmoe. I’ve already set up our desktop iCal clients with the necessary permissions for delegation. Joe Schmoe has allowed write access to his calendar as per the screenshot here.
It’s quite simple to add delegation to my iCal client, but what if I need to be able to write to Joe’s calendar with my iPhone? Simple enough. First, go to the Settings icon and click it. Click “Mail, Contacts, Calendars.” We’ll assume you’ve already added your own CalDAV account here for the iCal server. Let’s add another one. On this new CalDAV account, configure it just like you would configure for your own account. Use your login and password just like your regular CalDAV account. I would suggest you change the “description” to something a little more appropriate like “Joe’s calendar.”
After configuring the account, click “Next.” Assuming you set up your account and password correctly you’ll get back to the main calendars screen. Now here’s the trick to make this work. Click on the account again and go into the configuration. Click the “Advanced Settings” button near the bottom. What you want to do is change the “Account URL” to the short name of the user. In this case, Joe’s short name is “jschmoe.” I’ll change it there. Be sure to leave the rest of the URL intact.
Once you’ve made the change, click the left arrow to head back to the main configuration and once more to get back to the main account screens. Congratulations, you’ve now set up delegate access to your manager’s calendar. Now all you have to do to view the calendar is go to the Calendar icon like you normally would. Joe’s calendar will show there. You can select it by itself and write events to the calendar if you wish. That’s it!
If your manager isn’t lazy like my fictional one you could also have him keep “Write” unchecked in the original account delegation setup. That will provide read-only access to his calendar when you’re on the go. Of course, if you’re adept and using “invite” and the availability window you may not need to use delegation at all.
There you have it!
Also, one last plug. If you’re really interested in helping to make the calendar as functional and ubiquitous as email, please consider joining CalConnect. CalConnect is a consortium devoted to the standardization of all things related to calendars. They’re doing great work and I’m sure they would love the help.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=f4c60f4f-e05f-41f8-b8da-6b7f5b229335)
OS X Leopard and Snow Leopard servers have the interesting ability to cluster the mail services. The requirements to do such a thing carry a somewhat hefty price tag both in hardware and software, but it can be done. To make this go you’ll need to set up a fabric with some storage and make use of Apple’s clustered file system: Xsan.
We’re going to cover the setup of all this mess later down the line. For now, I thought I’d share with you a mishap that can occur when clustering mail services and how to get out of the snare without reinstalling your servers.
Mail services on Snow Leopard make use of several standard open source projects: dovecot (for IMAP and POP), postfix (for the mail transfer agent) and amavis/clamav (for message hygiene). These packages are available on just about any regular Linux or UNIX setup. Snow Leopard’s Server Admin utility generally takes the eye bleeding work out of administering these services. Hey, that’s what makes Apple servers great, right? All of these packages come preconfigured and requires very little in the way of administrative skills. That’s true until something goes wrong.
Imagine if you will… you’ve set up 4 Snow Leopard servers and clustered them with Xsan to produce a two-node active/active mail cluster. (Like I said, we’ll cover how to set that up another time). Now let’s imagine the horror of horrors: your Xsan implementation has absolutely, positively clocked out. Let’s say it’s clocked out so badly that you’re looking at an extended outage while you troubleshoot the issue.
Keep in mind that clustering the Mail services on Snow Leopard requires Xsan. There’s no getting around that. You just cannot have these services tagging the same data volumes without it. That’s Xsan’s job, after all… to manage all of that hilarity. Also keep in mind that Xsan requires some pretty heady thinking to avoid a single point of failure. If you manage to introduce a single point of failure into your deployment you may be facing this situation. Hopefully, you’ve implemented some type of backup strategy for your Xsan deployment. If that’s the case, chances are pretty good that you have a copy of the clustered Mail stores on another, non-Xsan volume that can be mounted and recovered quickly.
As a matter of fact, if you have such a volume with the data intact and your Xsan appears to be out of commission for a while, that’s where we are. You’ve mounted your backup volume onto a single server in the Mail cluster and have decided… Well, my Xsan is hosed so I can at least get the data mounted on a single server while I work on that, right?
If you were to open Server Admin at this point and try to reconfigure the mail cluster, you may start to bite your nails. To do this, you would open up Server Admin, click “Mail” on the left, then the “Settings” gear at the top. You would choose the “Advanced” tab and the “Clustering” subtab. You’ll note there that your Mail server is still configured as a clustered server. Normally, to change this configuration, you would click “Change” and walk through the wizard to set it back to a standalone server. However, I’m here to tell ya… it will fail.
You see, if your Xsan volume is not available (which, it isn’t in our scenario here), then Server Admin will do its best to reconfigure the mail cluster to standalone at your behest… and then error out. The error will read something akin to “FILE_NOT_FOUND_ERR for action ‘setState.’”
So what is going on here? After running through this wizard multiple times and trying different configurations you may notice several things. Many of the options you choose will not stick. If you were to monitor what is going on in /var/log/system.log, you may also notice that the bloody thing keeps trying to mount your Xsan volume. Yeah, it doesn’t matter if the volume is available or not – Server Admin expects to find it there to revert the configuration.
Now what?
Thanks to the magic of fs_usage in Terminal, you can figure out what Server Admin (and its command line sibling servermgrd) is trying to do. I’ll leave out the icky details on how I arrived at this conclusion, but I’ll hammer out what Server Admin did in the first place and what it’s trying to do now.
When you first set up a mail server in a clustered state, Server Admin performs several actions:
Postfix:
Dovecot:
AmavisD:
Note: the hidden directory referenced above is at the root of your Xsan volume. It’s named after the clustered server name you created. For instance, if you created a mail cluster called “MailXsan”, then the directory is physically located at “/Volumes/MailXsan/.MailXsan” and the configuration items listed above will be found deep inside there.
General plist file:
That last file was the hardest to figure out. It didn’t take much to realize that when you create the cluster, the old config files and directories are given the name “*.cl-rst” and the new configurations are symlinked out the Xsan volume. However, even after fixing those *.cl-rst files the Server Admin configuration utility would continue to bomb with the same error. It took some tasty analysis with “fs_usage -w -f filesys | grep servermgrd” to figure out that last plist file.
How does one unravel all of this? Again, assuming your Xsan volume is no longer available, go through the above configurations and reset things to the prior state. The steps are provided below. All of these commands must be executed as root, so be sure to use sudo in front of every one of them. Also, BE CERTAIN that the files exist in the way I have described. If you’re unsure of what you’re doing, ALWAYS list your directory contents before targeting files for removal. Additionally, I shouldn’t have to remind you that you should back up all of these files before you do anything, should I?
Now, rerun Server Admin’s mail setup utility and you’ll get through the whole thing. Be sure to point it to the new volume where your restored data resides. Voila, you’ve recovered your server to a single node service until you can get the Xsan crap cleared up.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=1f23739f-62f5-41b4-82dc-ba4f44c37def)
With all of the love the Macbook Pros have been getting recently, it was only a matter of time before the fanboys start clamoring for updates on the other pieces of hardware too. So, here we are, three days later and we thought we’d light the torches.
I was thinking aloud in a somewhat unrelated conversation about how nice it would be if Apple were to update the Xserve line soon. Since we have a clue about their thinking for processors, how long do you think it will be before we have updates on the Mac Pro and Xserve?
Better yet, what processors do you think they’ll have? Earlier in March, TUAW passed along the rumor that the Mac Pro was slated to receive the i7-980 processor (“Gulftown“) with six cores. Since the Mac Pro is typically dual processor, that would be 12 processor cores. Ouch.
It depresses me greatly that the press rarely gets excited about updates to the Xserve line. Those 1-U rack mountable servers pack some serious horsepower. What type of processors do you think the Xserves will sport?
We’ll have some fantastic information on Xserve configurations coming soon on our shows. We’ll probably wait until the platform gets updated before we cover the actual hardware, or we’ll find that podcast obsolete pretty fast.
So what do you think? Give us your thoughts on updates for the Mac Pro and Xserve lines. Start… now!
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=a12e62a3-2705-410f-a7f3-fdce6929b2fe)
Arstechnica has provided a fantastic write-up on the new graphics switching capabilities on the Macbook Pros introduced this morning. It also provides insight into how this is different from other solutions from Intel, AMD/ATI and NVidia.
This sounds like good stuff, although I am still a bit skeptical on performance increases. I’d like to just see for myself but, well, you know… that might be hard to do when you’re broke. The feature speaks very well to the strength of the Apple platform in achieving the perfect harmony of hardware and software.
The article is right here.
There’s no doubt in my mind that you’re well informed on the Macbook Pro updates that hit the market this morning. There’s also no doubt in my mind that you’re excited about the updates if you’re into that particular class of machine.
Apple‘s promise of integrating the i5 and i7 chips into the Macbook Pro line has been fulfilled and it couldn’t be any sweeter. The initial benchmarks (Gizmodo) are in and there’s lots to drool over. Combine these processors and graphics chips with 8gb of RAM and you will have one seriously mobile powerhouse.
As usual, I suspect we’ll see much more on the “hidden” features of these beauties over time. One of these hidden gems has already been tweeted – the possibility of an HDMI adapter for the mini DisplayPort. That brings all sorts of possibilities to the table.
I’d like to research the graphics chipsets and capabilities a little more. There are squees(!) of glee over the “automatic switching” offered by the sales literature on the Apple website. I’m somewhat skeptical of that type of power management, but I’d sure like to try it.
I’m sure there’s much more to come on this later, but all in all… it’s a great day to blow money on some Apple hardware, isn’t it?
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=0b27c836-1224-4ed1-af9f-0a5112932be1)
|
Copyright © 2010-2012 The Cat Convention. This website is a production of Red Abstract, Inc.
|
 |
Blabber back