To cut a long story short - how do you define multiple "From:" addresses for an email account in Mail.app?
I always thought you'd just have to create a separate account. But what if the 2 accounts are actually on the same server? Mail.app won't allow you to create two account with the same incoming server host name.
It turns out this is all very simple - just add the From: addresses to the Email Address: field in the Account Information tab, separated by commas.
That adds each one of those to the From dropdown menu of the New Message window. I came accross this because Apple did it when MobileMe came out.
This might not sound like much but it's a really cool solution to a potentially icky problem. Like having a mail server receive mail for multiple domains and suddenly finding out your users want to send mail from multiple domains...
I would like to take this opportunity to vent some steam over Apple iCal Server. I was going to simply file a bug about this, but even that didn't work. :-/
Yeah, that's what I get for some groups after the 10.5.6 server update. "domain CalDAV No Calendar Home Error / code 1" - WTF!!!! And the web is full of these reports. I can browse the principal just fine from a web browser at https://server:8443/principals/groups/whatever/ but iCal just won't work.
"Solutions" range from anything re-creating the group to down-grading your OD Master to Standalone and then back up again.
And can you guess what "fixed" it for me? That's right - just wait for about 10 minutes and keep pushing the "Add" button until it finally goes through. Yeah, I know...
10.5 in general has been the most difficult server upgrade Apple has ever gone through (if you look close there's actually a lot more changes in server than client this time), but iCal Server has been particularly problematic. Here's a list of things that are wrong with iCal server:
Documentation. The entire iCal Server Administration guide is 35 pages long!!! What the heck is Apple thinking? To bring a completely new product to market, which will obviously have many faults and missing features and then not even have the courtesy to explain them??? In addition to a technical admin guide (which should be more like 200 pages), they should have also some-kind of workflow document with different scenarios of how the calendar server can be used. Most companies will come from having no calendaring system at all so they need help with not only setting things up, but using a calendar in the first place.
Mobile syncing. You won't find this anywhere in the marketing materials, but the syncing features you get with iCal Server are extremely limited. You can't sync group calendars at all and you can only "upload" your personal network calendars - i.e. you can sync events created on your phone only to your local calendars!!!. As a matter of fact, none of the delegated calendars show up in iSync. Mention this to your sales-force before deciding to go with iCal Server!
The way that group calendars are managed doesn't make any sense. You can't just configure each user's group calendars, but have to configure the group account on some machine directly into iCal and then delegate rights to all the people who should have access to it. So you want to manage this centrally, you will have some Calendar Administrator account, that has to be a member of every group which is then used to set up the accounts and delegates. And don't forget to enable email for this account, because you will get a lot of bounced mail if you use the new group-based mailing-list feature. You also have to remember to create a delegate every time a new user is created since simply adding them to the group does nothing. Kludgy.
Delegation can get very messy if you have say more than 10 users. You can't delegate entire groups, so if you want to have every user see any other user's calendar in your organisation of 50 people, each one of those 50 will have add 50 delegates to iCal.
Access control is very limited. When you assign someone as your delegate, you have no control over which calendars he/she can see - they get instant access to every calendar and todo. Try to explain to your user why they can't have a "Work" and "Home" calendar so that their boss only sees the first one.
The web calendar is very much broken. To this day (remember, server is already at 10.5.6!), only the first occurrence of a repeating event will ever be shown in the web calendar.
Weird data store. Instead of using a database for calendar metadata, Apple chose to use extended attributes to keep track of such trivial things as who can access what calendar. Why? So that more admins would break their calendar servers by using a backup tool that doesn't preserve those attributes.
Invites. Everyone is used to getting an invitation via email. iCal Server doesn't do this - instead it hides it in the iCal application itself. This also has the side effect of not being able to invite people outside your LDAP.
These are just some things off the top of my head. You can find many more at Apple Discussions. AFP548 even did a special post on basically the same subject.
And while I don't entirely agree with Mr. Tatsu Ikeda, I do feel like Apple has made a lot of empty promises with 10.5 server and that iCal Server has been a big part of that letdown for many other sysadmins as well. I have some sympathy for Apple for being bold and bringing something really new to market and doing "the right thing" by actually creating some standards to go with it (CalDAV), but still...
Today I was reminded again of the fact that the only current virus-related threat on OS X are the antivirus software themselves:
That's 442 different VirusBarrier processes spawned off for no apparent reason in a totally normal user environment (Mail, Safari, TextMate etc). I noticed the problem when I tried to open an SSH connection but got the following error instead:
-bash: fork: Resource temporarily unavailable
That means the system has exceeded the limit of processes per user, which in Leopard is already pretty generous:
So I was unable to open any applications and slowly the machine just started to die. Simply disabling the automatic virus check didn't do anything, but luckily a good-old killall saved the day. Needless to say VirusBarrier has now been uninstalled.
I only installed it since it came as part of the Macupdate Promo Bundle, wanting to see if it was any better than McAfee's VirusScan, which believe it or not is even worse. If you use 10.5, FileVault and VirusScan, your machine is guaranteed to freeze within 15 minutes after login. McAfee knows about this problem, calling it a "performance issue" and seem to have just recently released a patch.
So anyways, I think it's important that people abstain from installing antivirus software "just in case" and only do it when there's actual need for it. I thought the "performance issues" were a thing of the past, (remember the Norton installs that hosed entire systems when the OS was upgraded?), but clearly they still do more harm than good.
I'm just finishing up my biggest deployment project yet - 72 Macs (70 iMacs and 2 Mac Pro's). 21 iMacs got new 1TB drives, all were upgraded to 4GB RAM and all of them went out in 4 different software configurations. With this sort of job, it really helps to have a plan. Here's one:
Planning and preparation
Determine how many different software configurations you have and how they relate to each other; name them. Look for differences and similarities. For instance, you may have 4 different sets, all of which share the same base system. Make the sets as modular as possible, but don't over complicate things - the whole idea is to save time and minimize errors. A monolithic image might be just fine if you have 60 identical setups to restore.
Design a worksheet which will be attached to every box. As a minimum, this should include the serial number of the machine, name of the software set, every hardware modification step and the name of the DeployStudio workflow used, all on separate lines, with a checkbox.
Collect all the necessary software, updates and license info. Check the web for any deployment hints for packages you haven't worked with before.
Software and testing
Build your workflows into DeployStudio. Create one for every software set you had defined. Don't be afraid to use different methods for building the payload (perhaps a DMG of a master machine for the base install, separate PKG's for 3rd party apps and updates, snapshot packages created with PackageMaker, custom scripts etc etc).
Take one machine from each set and test the correspoding workflow. Reboot several times, make sure you don't have any zombie postponed installs lying around, if you used that option.
Test some more. Check the logs for any suspicious errors.
Have a break, then test some more.
If you have the slightest doubt about the configuration, consult with the client. It's easy to fix a preference in one or two machines, but not so in 70, especially if they're shipped to different locations!
In DeployStudio, create a computer group for each software set and set it to run the corresponding workflow by default.
Hardware
Remove the brown cardboard from all the packaging, so you can scan the Ethernet ID's with a barcode reader.
Scan each serial number into a worksheet and print them out. Attach the worksheets to each box, use proper tape so they don't come off in transportation! The idea is that you can always match a machine to the corresponding box and worksheet.
In DeployStudio, use a barcode reader to scan the Ethernet ID on each box into the corresponding computer group. This will associate each machine with the software set and run the workflow automatically after authentication in the DS Runtime. Make sure you get the Ethernet ID, not Bluetooth or AirPort.
The idea is to do everything in passes - the same procedure to all the machines. This helps minimize errors as you can concentrate on just one task.
Start the deployment, carefully ticking off items on the list. Repeat until you're done.
The previous might not be the world's greatest plan, but I think it has some good points and is general enough to use in different situations + it uses DeployStudio. It also helped 2 guys get this job done in less than 3 days. :)
Passed the final exam in Apple's ACSA certification trail today and thought I'd write down some thoughts.
First of all, I'm really glad that the ACSA cert exists. It gives working geeks something to strive for, something meaningful to show when applying for a job and not to mention some much-needed leverage for negotiating a raise. It's also just a great way to learn new stuff, which becomes harder and harder as you become the "go-to-guy". Owning a cert doesn't automatically make you smarter than someone else, but it does show that you've made an effort and take your job seriously.
I would recommend people take the courses, not because you necessarily need them to pass, but because they are really good (I didn't take any myself but have been involved in Apple's training programs to know that they take it really seriously) and you will get a lot more out of the whole experience as well as meet some smart people. This isn't as easy as it sounds - someone in Finland would have to travel all the way to Denmark to attend the 10.5 Directory Services course, which is not only expensive (the course alone was 2 700 EUR), but also logisitically very difficult for an SA (you have to be away from work for a week).
If you can't take the courses (like me) then fear not - you have some great books to lean on. I've gone through quite a few computer books and Peachpit's Apple Pro Training Series are among my favourites. They're great for self-study and also work pretty well as reference. You can even use them to give classes (all of Apple's own courses follow the same books). Much like Mac apps, the all share the same structure and are very easy to follow.
Here's a short rundown of the books and the respective exams which I hope will prove useful to someone (yes, I read all of them cover to cover):
The Essentials books are always the hardest - they have to cover a lot of ground and consider the widest range of readers. I liked this one alot more than 10.5 Support Essentials, but it was still quite a chore to go through. And 10.5 server doesn't make it easy either, the different installation types are I think particularly annoying. Some nice questions about ACL's.
I think I enjoyed this book and exam the most. Excellent, practical stuff that was really relevant to what I was doing at work. Not too thick, but not missing anything important either. Great reference material. Exam didn't have any silly "we're just checking if you payed for the course" questions.
This one was the scariest for me. The book is really dry and it took a lot of black tea to stay awake while reading it. Lots of theory, also, lots of repetition (which might not be such a bad thing). Difficult to prepare for due to the heterogenous nature of the subject matter (I actually installed Windows Server 2003 on my MBP, but that was it...). If you could only go to one course, I would probably recommend this one, depending how important Directory integration is in what you do.
A lot of facts to remember, some tough questions, stuff you don't just remember, but have to actually think about to get right. I honestly thought I was going to fail this one.
I was really excited about this book (failover, backups, monitoring, documentation... you name it!) and it was indeed really good. I took it with me on my trip to Russia so I had time to really go through it back and forth and indeed learned a lot. I like Mr. Marczack's concise and confident writing style, both in this one and over at MacTech.
I think the part on scripting could've focused on Bash alone and instead of introducing Python and AppleScript, have more practical examples.The exam was a disappointment - I think it had the most "pointless trivia" questions of the four, stuff that no-one should ever memorize (ie what algorithm srm uses or what's the name of the protocol an AP BS uses to talk to a RADIUS server!). It almost felt like the book and exam were done by two different people.
Some random recommendations for people who want to get through without the courses:
Get all the books
Read them and make sure you can answer all the Review Quiz questions. This should guarantee you get at least a passing grade.
Make a plan - say 1 exam every month, or whatever feels good. This helps you keep on track.
Aim for 90% correct answers. I think over 90 is really good, for 100% you either have to take the course or be really lucky. :)
Probably the most general indication that something's wrong with a server is an unusually high load average.
Typically this will be a stuck DirectoryService or httpd or imapd process which is then slowing everything
down. Luckily it's pretty simple to keep tabs on load average, for example by using the following script:
MAILTO="filipp@mydomain.tld"
COOKIE=/private/tmp/loadcheck
LOAD=$(uptime | awk {'print $11'} | sed 's/,/./')
SUBJECT="$(hostname) is under heavy load!"
if [[ -e $COOKIE ]]; then
exit 0
fi
BODY="$(ps -rax | head -n 4)"
if [[ $(echo "print $LOAD > 1" | bc) -eq 1 ]]; then
echo $BODY | mail -s "$SUBJECT" $MAILTO
touch $COOKIE
fi
exit 0
This will send the email only once and you'll have to delete the cookie to reset it.
Combine that with a launchd.plist running it, say every 60 seconds, you should be able to spot problems before your
users do.
If you've ever tried to build a deployment image directly from individual iLife packages (onto say a sparse image),
then you've no doubt seen this error message:
installer: Error - You are attempting an unsupported installation. If you wish to install an individual
application, please use the iLife installer and select the Custom button.
Bummer. Well, luckily there's a really simple workaround:
Why yet another rsync wrapper for the Mac? Because I really felt there was't one that met my needs:
Simple Finder-based source selection - just label everything important with the Violet
label.
Exclusion list support - if there's anything inside the important folder that you
don't want to back up (say Microsoft User Data in you Documents), just mark it
with a Gray label
Added flexibility via Smart Searches - just save a search as "Macup" to really fine tune
your selection criteria.
Easy scheduling via iCal
Using rsync is really fast, reliable, transparent and good for the soul :P
I turned to OpenFire shortly after discovering that iChat server doesn't support
group-based buddy lists. There's only the really crude jabber_autobuddy script,
but even that has to be run every time you add a user and sometimes users get stuck
at a "Waiting for authorisation" message. No thanks.
A list of things I really like about OpenFire:
Support for group-based buddy lists
Conference support and chatroom management
Has a real admin interface
Can work with any LDAP server
Runs on 10.4, including Workstation
In all, a comprehensive instant messaging solution (+ they even provide a x-platform Jabber
client)
There's some gotchas with the Open Directory integration, but thanks to the LDAP wizard
it's not impossible to figure them out.
Stuff I haven't figured out thus far:
AV support
Screen Sharing (which would be great for end-user support)
Avatars (I think this is because OD stores the user picture as data while OF expects a URL)
Anyways, definitely worth a try if you're fed up with iChat server and it's animic admin
features. I think it's a much better product altogether.
IM in the Enterprise is a Good Thing - it helps alleviate interruption (email), improves
communication (esp. sending files, screenshots of error messages etc.) and improves the SNR of
corporate email. Maybe the biggest factor in the adoption rate is automatic buddy lists (there is no way you can get your users on board if
they have to manually add each employee to their contact list) and it's really sad that Apple couldn't
get this right.
Some months ago I attended a Symantec Mail Security training course (a kickass system, btw).
They had this little graphical testing utility which accepted an SMTP server address,
from field, etc and a list of .eml files and the number of copies to send.
I thought this was a brilliant tool and was pretty surprised to not find
an equivalent on the Mac. However, OS X being Unix, it took about 30 minutes
to write one from scratch, this time in Ruby:
10 is the copies to send, TestMail is the name of the folder containing
the .eml files. This depends requires the net/smtp gem being installed, but IIRC it
comes with Leopard by default.
I think using .eml files is really powerful since you can test it with all manner
of encodings, headers, attachments (including viruses) and spam.
The name comes from the instructor who referred to sending test mails as "spraying the server with mail".
:)
The script in it's entirety:
require 'net/smtp'
if ARGV.length < 6
puts "Usage: mailspray.rb server port from to copies directory"
Process.exit
end
server, port, from, to, copies, directory = ARGV
Dir.glob(directory + "/*.eml") do |f|
puts "Sending " + copies + " copies of " + File.basename(f)
msgstr = ""
File.open(f, "r") do |l|
msgstr = l.read
end
Net::SMTP.start(server, port) do |smtp|
copies.to_i.times do |i|
smtp.send_message msgstr, from, to
end
end
end
Tired of constant downtime, slow performance and general crappiness of MobileMe's webmail
I decided to do something about it and created mobilemeisdown.com -
a Rouncube install that's configured to work with MobileMe.
Apple made a bold move with migrating to a very young development platform (certainly in terms of applications
on this scale) and set new standards in web UI design, but webmail is an important tool
for me, goddamnit and I can't have it just disappear in the middle of the work day or
not send out mail or whatever...
index.sucatalog lists the actual update packages themselves whereas we want a list of SU servers.
catalogs.sucatalog looks exactly like mirror-config-1.plist, except that it lists your master SUS's
address.
There's now two dashboard widgets that I find actually useful, the first is the excellent dashLicious and the second, the newborn DashLog:
It allows you to remotely monitor any log file (using good old tail -f). All you need is the widget, some SSH hosts defined in your .ssh/config and passwordless authentication configured.
On the back you can select some typical log files or define a custom one:
This thing's straight out of the oven so there will probably be some stinky bits in there. I have a couple of ideas how to make this more powerful and maybe even one day surpass Console.app. It's the first widget I've ever built using Dashcode. You can download it from here (256kB ZIP).
And, yeah, I turned 28 today :-P
SELECT DATEDIFF(NOW(), date_of_birth)/365 FROM `filipp`
--> 28.0192
So you've just finished up setting up the new server at the office and now you need to send account info to 45 people. You can make an email template and then find/replace each user's info in or just create a generic one (ie afp://newserver/yourusernamehere). The first is tedious and error prone, the second seems fine... until you get emails from 25 people who are not able to log in because they just click the link and their password doesn't work.
That's where Templar comes in - just create two files - an EML with all variables marked in C-style ($0...) and a CSV file to populate the variables (from col $0 etc, each row representing a new email). Then just drop the two onto the AppleScript droplet and you have all the email ready and waiting (it doesn't actually send the mails, just opens them up). $0 is substituted with the first column, $1 with the second etc.
You can download the droplet from here. Requires 10.5 or later (or a 3rd party PHP install, because of filegetcontents ()).
