sudo launchctl unload /System/Library/LaunchDaemons/com.apple.hwmond.plist

which initially threw an odd error, looked at the list of loaded items by running launchctl list on the server and noticed that it was gone. I restarted my XServe and sure enough it had loaded itself. Figuring that there must be something in the OS automatically loading this on each reboot I started searching ways to modify or disable hwmond on my server. In my case I needed to stop the high CPU usage so badly that I was willing to make the tradeoff, of not having hardware monitoring enabled on my system for a modicum of stability for my users, and since this was an email server it seemed like a fair tradeoff. Especially since it looked like the hwmond process could be the process that would cause the most damage to my system if it was allowed to continue and then would be the thing to notify me that the hardware had failed due to extremely high CPU usage over a long period of time. I ran across a post made by Apple http://support.apple.com/kb/TS2066 and decided to take a read, basically the issue that this resolves is hwmond not working and having a tag in the plist file that disables hwmond. Since this was my goal I did the opposite of what the knowledge base suggested, instead of removing the said code from the plist, I put the code into the plist and then rebooted my XServe.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
          <key>Label</key>
          <string>com.apple.hwmond</string>
          <key>OnDemand</key>
          <false/>
          <key>Program</key>
          <string>/usr/sbin/hwmond</string>
          <key>ProgramArguments</key>
          <array>
                    <string>hwmond</string>
                    <string>-s255</string>
          </array>
          <key>ServiceIPC</key>
          <false/>
          <key>Disabled</key>
          <true/>
</dict>
</plist>

Once the server rebooted I was back in business. My server’s CPU usage was back to normal and life was grand. Three days later, I restarted my server for an update to Virusbarrier the software I use to help block unwanted attacks on my server, and the high CPU issue returned. I looked at the hwmond.plist file and sure enough it had been re-enabled. I applied the fix above and restarted and it seemed to take. Well this is by no means a permanent fix but then I found this forum post https://discussions.apple.com/thread/3138473?start=0&tstart=0 It seems as though Apple has been informed of the issue and they are working on a fix. But as an update sceptic I find myself chuckling inside, the 10.6.9 update will claim to fix the hwomond cpu issue but what new issues will lie lurking in the wings to terrorize my system? Only Apple knows or maybe they just don’t have a clue. Hopefully they will come up with a fix, until then I have learned my lesson, I will not update my system so cavalierly in the future. I welcome your feedback and let me know what you have done to combat this issue.

Hello Jon,

I read a few posts of yours regarding 10.6 Groups functionality w/calendar, and I’m hoping really just for your opinion. And if you’re just too busy, I understand that, as well, but maybe you can take a couple of minutes and humor me!

For what it’s worth, in a former life I was a much more in-the-trenches Mac tech and developer (pre X), and now am just a semi-power user. As a complete aside, I’m
also a former Now Up To Date & Contact evangelist, and I sorely miss a lot of what that product had right out of the box.

So, that said, I run 10.5.8 Server, and really need to share Calendars andContacts, using Groups for permissions. The CalDav server works pretty well, great with iCal, kind of cumbersome to set up paths with Sunbird on Windows boxes, but works. The Wiki cal…was pretty disappointing in that it only displayed the primary calendar. And for all the meandering I’ve attempted with Groups, it hasn’t really gotten me to a good end, and client setup is again, cumbersome.

I do like the idea of Win users (or anyone, especially remotely) being able to just open a browser and view multiple calendars, for obvious reasons, as opposed to using an application (Sunbird) and setting up a half dozen calendars and paths, for instance. For this reason I’ve dabbled with Google Apps, using their shared Cals, and iCal as client for my Mac users, etc. This works quite well…no Groups permissions per se, but at least easy to assign per calendar privileges to individuals, and thereby pretty easy for individuals to log in and see all. I’ve messed with Google Groups, and again, got a little cumbersome. Worked, but cumbersome.

I ALSO very much need a good Shared Contacts solution, and Google (and everyone) still fails badly on this score, as far as I can tell. It appears that 10.6 Server will do what I need it to via CardDav, hopefully…?

SO THE QUESTION IS…should I bite the $500 bullet and buy 10.6 Server? Specifically, to your knowledge:

1) Does Address Book sharing really work now? As in, the ability to specify Groups you do or do not want shared? I’d thought 10.5 was supposed to, but was disappointed to find out it was strictly LDAP-related. So once bitten, twice shy. If it does work well, that might be reason enough for me to make the switch, even if I kept using Google calendars…

2) That said, does iCal Server now actually work with Groups, for real, for assigning Group privileges and access?!

3) …and if so, can you now use a browser to view multiple calendars, assuming you have proper Group privileges?! Or a CalDav client?

If you’ve gotten through this, thank you sincerely. Honestly, any thoughts are appreciated. When I was more ‘in the game’ I had a big network of coders and developers to chat out things like this, but now I’m pretty much out of the fold.

Sincerely,

Karl Zarling

1. Migrating Mailman data from one server to another.
I had many problems making sure that mailing lists, users, and archives were preserved when moving from our old server to our new server. Here are the following things you must do in order to ensure that the lists are preserved.

You must backup the old mailman lists these are more than likely stored in the /var/mailman directory

sudo cp -Rp /var/mailman /Volumes/setting-backups/

Once your ready to restore the files to the new server run

sudo cp -Rp /Volumes/setting-backups/mailman /var

the -Rp flags relate to the fact that it is a folder and that you are going to restore the permissions, once your done you will need to login through SSH or on the server itself and run

cd /usr/share/mailman/bin
sudo ./genaliases

the ./genaliases command will take the lists, and it will generate aliases for them. This plagued me for a while before I realized that when you migrate to the server, this database needs to be built.

2. Change the hostname of of your Mailman Server
I have had to do this as well, normally the mailman web interface can be found at http://example.com/mailman/admin for the administrative side or http://example.com/mailman/listinfo for the list information side. If you are going to change the hostname of your server to example2.com then you will need to use the command line tools to move the lists over.

cd /usr/share/mailman/bin
./withlist -l -r fix_url $listname -v

This will update the host names for $listname from the main configuration file, and -v shows you what the changes are. Remember to change $listname with the actual name of your list, you will have to do this for every list you can however run all of the lists at once by running the command multiple times like so.

cd /usr/share/mailman/bin
./withlist -l -r fix_url $listname -v
./withlist -l -r fix_url $listname1 -v
./withlist -l -r fix_url $listname2 -v
./withlist -l -r fix_url $listname3 -v

3. Retrieving a text list of users subscribed to a list
I have seen this question asked in almost every forum that I have visited, there are multiple ways to do this however I recently found out that Mailman has a built in tool that will automatically grant you what your looking for in the form of an email daemon. First, you must be an administrator or moderator of the list in question. Second you must know the password to the administration area for the list in question.

You can get a list of users by sending an email to the list at $listname-request@yourdomain.com where $listname is the name of your mailing list. With the the following command in the subject line and the message body.

who $listpassword

where $listpassword is the password of the list in question, the list of users will be sent back to you in the form of an email.

4. Create a Mailman auditing script
These commands can be used to export a list of users and then have that list automatically emailed to you so that you can regularly be reminded to make sure that your mailman lists are free from errors, and or people that should no longer be on the lists. I have created two scripts that do this.

Script #1: The list querying script

#!/bin/bash
 
cd /usr/share/mailman/bin/
 
./list_members -f Internal > "/scripts/lists/audit/Internal.txt"
 
touch "/scripts/lists/Internal.txt"
 
echo -e "XXX Mailing List -- For Auditing Purposes \n\n This is an automated email, please check your list of subscribers for accuracy, if there is a change that needs to be made please contact XXX, at XXX@XXX.XXX, thank you. \n\n" >> "/scripts/lists/Internal.txt"
 
cat "/scripts/lists/audit/Internal.txt" >> "/scripts/lists/Internal.txt"
 
SUBJECT="XXX Mailing List"
 
EMAIL="XXX@XXX.XXX"
 
EMAILMESSAGE="/scripts/lists/Internal.txt"
 
mail -s "$SUBJECT" "$EMAIL" < "$EMAILMESSAGE"
 
rm "/scripts/lists/Internal.txt"

This script runs the commands and generates the list, it then adds on the email text above the list of users and then sends it out as an email. I would name this script the name of the list so for example $listname.sh and then chmod the script 700 so that it is executable. You will want to use the above template for each of your mailing lists and save this into multiple scripts.

Script #2: The the scheduled script

#!/bin/bash
 
cd "/scripts/"
 
./list1.sh
./list2.sh
./list3.sh
 
rm -R "/scripts/lists/audit"
mkdir "/scripts/lists/audit"

You will want to schedule this script, I have mine set to once a month, what it does is, it runs all the scripts listed each script above uses the first template to query Mailman, generate the lists, append with email text and then send out to the list moderators.

There is a bit of trial and error here, first of all the user account must have sudo rights, so you may need to add the user running these scripts to the sudoers file or make them an administrator. Scheduling is a matter of setting up a crontab, I am using

0	0	1	*	*	/bin/bash /scripts/run.sh

this will make sure that it runs on the first day of each month.

5. Reset the Mailman master password
I do this from time to time to make sure that I and the IT Staff at our organization have access to every list on the Mailman roster, but also as a security point, the password changes once every quarter. You can do this via the command line by running.

sudo /usr/share/mailman/bin/mmsitepass

It will prompt you to enter a password, and confirm. I suggest that you choose a strong password. You can also change a single list password through the command line as well.

sudo /usr/share/mailman/bin/withlist -l mylistnamehere
import sha
m.password = sha.new('supersecretpasswordhere').hexdigest()
m.Save()
{ctrl-D}

The above will change the admin lists password and encrypt it at the same time.

Well I hope you enjoyed my Mailman tips and tricks, please feel free to tell me of any other Mailman tricks that might help out the Mac community, as always comments are very welcome!

setup the 10.6.2 Snow Leopard server clean before I did anything I setup DNS on the server and manually retyped and rechecked all of the DNS records from the 10.5 server to the 10.6.2 server. Once I verified that the DNS records were set. I checked the server’s DNS by running sudo changeip -checkhostname and it came back clean. Great good to go, or so I thought.

I had setup split horizon DNS on the server, the Open Directory Master, has already been setup on a single use Mac Mini Server. The Mac Mini Server is running the ODM and DNS. The DNS on the Mini is self referencing and my router has the public ip mapped to the private. The new Mail server (10.6.2) also running DNS had a record pointing to the public ip of the ODM. Great, next step bind the mail server to the ODM so that I can start to migrate mail accounts.

I was working on this project around 10:00pm in the evening not knowing how long that it would take to migrate the accounts from Cyrus to Dovecot, but I had studied the Apple upgrade instructions for weeks prior so I felt like I had it totally under control. I followed the instructions and used the code from page 42 of the manual.

sudo /usr/libexec/dovecot/migrate_mail_data.pl --moveMail 0 --cyrusBin "/Volumes/10.5 Server Volume Name/usr/bin/cyrus/bin" --database "/Volumes/10.5 Server Volume Name/var/imap" --sourceSpool "/Volumes/10.5 Server Volume Name/var/spool/imap" --targetSpool "/var/spool/imap/dovecot/mail"

The script will tell you if your doing something wrong, which is helpful. My biggest question was how long would it take to migrate 30GB of mail to the new mail server. The answer, exactly two hours. I had decided that instead of using a firewire cable to connect the two servers together that I would simply pop the HD out of the old mail server and put it into the new server. This made a huge difference in the time of migration.

Once it finished I turned on mail, and everything started working fine. Great! I cleaned up my tools and logged out of the server and went home around 2am. The next few days were pure hell. As mentioned above I decided to use split horizon DNS. It was my first attempt at doing this and what I had noticed in the logs were a myriad of disconnect warnings every 5 min the mail server was getting disconnected from the ODM and then reconnecting causing some major issues.

The log files were filling up so fast that they were causing kernel panics, I had to reboot the server many times once every couple of hours, I decided to call Apple. The Apple representative captured my logs, and promptly told me that I would have to reformat the hard drive and completely start over. I told him that this was a clean install and that no way would I be starting over. He offered no other solution or advice other than telling me that it was not normal for a new server to have kernel panics this early in the game.

I decided to check my DNS turns out that the route statement in the router, was not properly entered. It was getting to the server but it was unable to retain a connection. I re-entered the route statement correctly and then rebooted the router. Almost immediately the issues stopped. Apple has come a long way in their migration capabilities if your ever having issues with your 10.6.2 mail service DNS is almost always the culprit!