| The Ultimate Business Machine Technology, business And, not least, about by: Bernard Teo
|
The Ultimate Business Machine - ArchivesList of Categories : Database * Technology * Commentary * Singapore * Travel * Fri 09 Nov 2007 Leopard 10.5.1 - just testingCategory : Technology/JustTesting.txt I've downloaded the developer build of Leopard 10.5.1 for testing. This is what I have to go through to test each release of OS X. First, I've started a test machine on my other broadband line, running Leopard 10.5.1. This will host a domain that I always use for testing - lifeassets.com (a domain that will eventually be used by my wife, who is a financial adviser). I'm so glad I snagged that domain name before someone else did because it sounded so right - Life Assets. It's about financial independence, health, a balanced life, family, happiness - all assets in life's balance sheet. There are loads of ideas we can build around this core concept. So, the first thing to test is that the domain name works - that it will lead people looking for the lifeassets.com server back to my test machine (which, incidentally, is an Intel-based MacBook running OS X Leopard 10.5.1). I use DNSUpdate to keep my public IP address sync'ed with the domain name, even though I'm on a broadband line, where the IP address changes periodically. I have a Unix shell script written by my friend, Hai Hwee, that does this, too, and I plan to merge this into MailServe for Leopard so people running mail servers on dynamic IP addresses will have one less piece of software to worry about. I keep looking for things to eliminate - buttons, fields, tab panels, whetever - e.g., in MailServe for Leopard, I've combined the Start/Stop/Restart buttons into one button. There used to be one set for each function - Postfix, POP, IMAP, Fetchmail - so, that's a lot of buttons eliminated. To test that the domain name works, I've started up Web Sharing in the Sharing Preferences for the server machine and I try hitting lifeassets.com using a browser on my other broadband line. The Apache test page comes up, so I know I'm set and I can move on to concentrate on my mail server. I'm amazed so many people skip this step. When they can't hit their mail server, they may already have the mail services, like SMTP, POP and IMAP, running correctly, but they simply can't reach their server because they hadn't managed to get the domain name-IP address mapping set up correctly. So they thresh about, solving the wrong problems in an ever-widening circle. You need to check that you can reach the server via its domain name, both from outside and also from inside your local network if you've situated the server behind a router (because you may have one of those routers that don't know how to route outgoing packets back to a local machine that has been port-mapped to a public IP address). You need to do this so that you can be sure that any problem that arise after that step would be solely due to the introduction of the mail server. So, if the domain name-IP address mapping works, I launch MailServe for Leopard and start up Postfix and the POP and IMAP services. With SMTP authentication turned off and the server set to relay mail for machines on the same network (the default setting), I try to send mail from a client machine on the local network to, say, my .Mac account. I look into my .Mac mail and, true enough, the message arrives and I reply to it. With the mail client set to retrieve from the lifeassets.com POP server, I can see the reply coming in, signalling that outgoing SMTP and POP work on my Leopard server. I turn off POP and create an IMAP account, and I can see the message in the IMAP Inbox. Then I create an IMAP folder, and move the message into it, and all is well on the IMAP front. So ports 25, 110, and 143 are all working. What about SSL? I create a test cert using the MailServe interface and turn on SSL modes for POP and IMAP and repeat the process described earlier. If all goes well, I can conclude that ports 993 and 995 are working properly. And the cert creation process, too. Next, onto SMTP Authentication. For that, I move my mail client onto the other broadband line. Now that I'm not on the same network as my server, I'll need to authenticate with it to send mail through. But first, I need to test that I can't send mail through it without authentication. You wouldn't want your server to relay mail for all and sundry on the Internet. So, I send mail and it gets stuck in the Outbox and that's good. I set MailServe for Leopard to relay mail for clients who authenticate and I choose the simpler OS X built-in accounts method as the authentication mechanism. I change my mail client setting to send the authentication parameters to the server and try sending the stuck message again. This time it goes through and I'm smug. Lovely, isn't it. Then I try to do the authentication via SASLDB. This was where the smile was wiped from my face for two whole months. Stuck while I try to solve it. Until I found it was an Apple bug. Now, I try to send a new message and ... it doesn't go through. The worry comes back. But the I remember. Of course, it doesn't go through. I hadn't changed the authentication parameters on the mail client to use CRAM-MD5. I make the change and, swoosh, the mail goes through. Phew! I never stop worrying aboout this - that Apple will break it with each software update. Now I test SSL all over, and POP and IMAP all over again, for the mail client connecting over the remote network. It all gets to be boring, until something doesn't work and then I'll take boring, anytime. What else, do I need to test? Oh yes - "Require SSL" - for all three protocols. If you don't use SSL, you can't connect. Period. MailServe users wanted this, so MailServe users get this. Also, alternate SMTP ports - MailServe has the ability to open up more ports, e.g., 2525 or 52525, for mail clients. Of course, we have to test SSL and non-SSL modes all over again for these ports. And the ability to receive mail for additional secondary domains. There's also the Virtual Alias Domains variant, where mail for the same user in different domains go to different mailboxes. What else? The log buttons - the Postfix and Fetchmail log. Even a simple thing like this could freeze the first release version of MailServe for Leopard. Which reminds me, we've got Fetchmail, too. How can I forget? Such pain, so many more permutations. Fetchmail accessing POP, IMAP mailboxes, with or without SSL, keep, no-keep, polling intervals, time-out intervals, multi-drop mode. At this point, if you're not tired reading this, you're a masochist, just like me. I can go on and on. In MailServe for Leopard, I have a new mode for configuring the mail server - as an admin user logged in using a non-admin account. So that creates another cycle for testing. Then I always have to remember to test against an installation without Xcode loaded - in case I've inadvertently used a Unix feature that's only available if Xcode is installed. Of course, a lot of Mac users don't know Xcode from the Da Vinci Code. So, all that testing. It really is a lot of work. |
Mac@Work
Services running on this server, a Mac Mini running Mac OS X 10.9.2 Mavericks:
all set up using MailServe, WebMon, DNS Enabler, DNS Agent, VPN Enabler, Liya and our SQL installers, all on Mavericks. |
||||||||||||||||||||||||||
