Xen - Issues with Windows DomU client clocks

Time is off by an hour in my XEN vm

Quote:

There is a RealTimeIsUniversal registry flag hidden in the windows registry that can be set (its not in by default) to let Windows interpret the RTC as UTC as well.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] "RealTimeIsUniversal"=dword:00000001

Summary:

The ultimate solution is to probably run an NTP client under the Windows environment to force the software clock to slave properly.

Dovecot - Upgrading Notes

At the office, we're using a virtual Dovecot server where each person's mail folders are owned by an unique user in the Linux account system.

Dovecot: Virtual Users - covers the basics

Dovecot: UserIds - explains why we use different UIDs for different accounts

Dovecot: LDA - explains how to setup the "deliver" executable to deal with multiple user IDs.

Multiple UIDs

If you're using more than one UID for users, you're going to have problems running deliver. Most MTAs won't let you run deliver as root, so for now you'll need to make it setuid root. However it's insecure to make deliver setuid-root, especially if you have untrusted users in your system. You should take extra steps to make sure that untrusted users can't run it and potentially gain root privileges. You can do this by placing deliver into a directory where only your MTA has execution access.

All of which means that whenever we update Dovecot with "yum update", we need to make sure that we fix up the Dovecot "deliver" executable file (which uses setuid) to also match.

So let's figure out which "deliver" we need to fix up each time:

# find / -name deliver
/usr/local/libexec/dovecot/lda/deliver
/usr/libexec/dovecot/deliver

Alternately, look at Postfix's master.cf file:

# grep "deliver" /etc/postfix/master.cf
# grep "deliver" /etc/postfix/master.cf
# Many of the following services use the Postfix pipe(8) delivery
# The Cyrus deliver program has changed incompatibly, multiple times.
flags=R user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension} ${user}
user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user}
# Other external delivery methods.
flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/lda/deliver -f ${sender} -d ${recipient}
# flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}

The key line in that jumble being:

flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/lda/deliver -f ${sender} -d ${recipient}

If we take a look at the file size, ownership, attributes and security settings (for SELinux):

# cd /usr/libexec/dovecot/
# ls -la deliver
-rwxr-xr-x 1 root root 802824 Jul 24 06:32 deliver
# ls -lZ deliver
-rwxr-xr-x root root system_u:object_r:dovecot_deliver_exec_t deliver

# cd /usr/local/libexec/dovecot/
# ls -la
total 24
drwx------ 2 vmail vmail 4096 Jun 16 23:00 lda
# ls -lZ
drwx------ vmail vmail system_u:object_r:bin_t lda

# cd /usr/local/libexec/dovecot/lda/
# ls -la deliver
-rwsr-xr-x 1 root root 802824 Aug 12 18:12 deliver
# ls -lZ deliver
-rwsr-xr-x root root system_u:object_r:dovecot_deliver_exec_t deliver

What we see here is a couple of things regarding how the Dovecot LDA is setup.

1. The Postfix master.cf file controls which "deliver" gets used for local delivery of e-mail. (The "deliver" executable is part of Dovecot, so we're using Dovecot for local delivery.)


2. /usr/local/libexec/dovecot//lda/deliver - this is where our "setuid" version of the "deliver" executable is located


3. The "lda" folder is owned by vmail:vmail (limited access) and only the vmail user can access the contents of the folder. Postfix knows to use the vmail user because that's what we told it to do in the master.cf file.


4. Both the official "deliver" executable (in the /usr/libexec/dovecot/ directory) and our "setuid" copy have the same byte size, date/time, and are both labled as "system_u:object_r:dovecot_deliver_exec_t" for SELinux.

The steps that we take when we update Dovecot are then:

1. yum update dovecot - updates the Dovecot executables to the latest version over at the atrpms repository


2. cp --no-preserve=all /usr/libexec/dovecot/deliver /usr/local/libexec/dovecot/lda/deliver - copies the new deliver executable over to the lda folder where we will setuid on it


3. chmod u+s is what we use to set the setuid bit on the copy in the lda folder, but we shouldn't need to do that once we set things up initially


4. service dovecot restart - restarts the Dovecot service using the new executables


5. grep "AVC" /var/log/audit/audit.log | tail -n 50 - look for any errors relating to Dovecot

New smartphone?

I'm sorta in the market for a new smartphone. What I have now is a Motorola Q from 2006. I've been mostly happy with it (except that it wasn't a touchscreen device), but it's been giving me more and more trouble lately. And the cell coverage by Verizon is, frankly, horrid at my current place of residence. Which makes the phone rather useless for me at home.

Back when I bought the MotoQ, I made the mistake of not researching software requirements before buying. I didn't understand that the non-touchscreen version of Windows Mobile was not the same as the touchscreen version of Windows Mobile. Which means that there are a lot of applications that I simply cannot run on the MotoQ (especially Pocket Quicken).

So this time around, I'm going to go in the opposite direction and look at the software that I want to run, then decide what devices will run it.

Pocket Quicken

Oh look, Pocket Quicken now supports the non-touchscreen phones like MotoQ. Basically, I can go with anything except an iPhone or a Blackberry.

CityTime Alarms

Only works with Windows Mobile 5 & 6, or the PPC 2003 version. But there are also versions for SmartPhones and Palm OS.

Agenda One

Windows Mobile 5 & 6.

IM+

BlackBerry, Windows Mobile, Symbian, J2ME, Palm OS and iPhone/iPod Touch!

zaTelnet Professional

MS Smartphones and Pocket PC

Update #1 to Current frustrations with Thunderbird

Well, I started up Thunderbird in safe mode. If you have installed Thunderbird in the default location, that's as easy as pressing [Windows-R] (or Start, Run...) and entering the following:

C:\Program Files\Mozilla Thunderbird\thunderbird.exe -safe-mode

What I found is that, although the error still occurred, Thunderbird was a lot better about not hanging up while retrieving e-mail from large IMAP mailboxes.

So I'm going to uninstall most of my add-ons and see if I can make things work better. Disabling the add-ons didn't have any effect, so I think I'll have to completely remove most of them instead.

To give you an idea of what I consider "large". I have an IMAP account on our mail server that contains 17GB (2,000,000 messages) worth of e-mail. I have another two accounts that contain 1.7GB (40,000 messages) and 2.5GB (200,000 messages) respectively. However, none of the individual IMAP folders have more then 60,000 messages each. And most of the large folders only have 15,000 to 30,000 messages.