On Mon, 2011-09-19 at 21:02 +0200, Philip Achenbach wrote:
> Hello Andrew, hello list,
>
> I have updated my installation of DAViCal to 0.9.9.5 a few days ago
> and have since encountered a few regressions. My setup is based on
> Debian 5 (Lenny) and uses an Active Directory via LDAP as the user
> provider. The users mainly use Apple devices (iOS 4.3, Mac OS X 10.6 +
> 10.7), one uses Evoultion.
>
> Since the update, some of the user-records in the database have been
> updated to become invalid: The fields "active" and "email" in the
> table "usr" has been set to NULL (Should the "active" field really be
> NULLable?). Additionally, the fields "displayname" and
> "default_privileges" of the "principal"-table have been set to NULL.
> Afterwards, those users did neither appear under active nor under
> inactive users in the administration interface. A synchronization of
> the LDAP tree with DAViCal (via the administration interface) did not
> help here. So i modified the "active"-field manually to restore the
> users. I have not yet found out which action triggered this update.
> In a short test, the LDAP-related fix from git (Bug #3409180) did not
> help here, and the problems don't sound exactly related, but if you
> think this fixes the problem I might test it once again.
Hi Philip,
It looks like my LDAP crue let me down here :-)
Unfortunately I don't have an LDAP server myself and nobody has asked me
to provide support for any LDAP-based installations. I've had a few
post-release fixes for LDAP things which were broken in 0.9.9.5 and was
planning to release a 0.9.9.6 with the fixes that have been sent to me
so far, but what you're saying here suggests that there might still be a
few regressions nobody has told me about.
From one problem that was discussed on IRC earlier today it seems like
the 'active/email/???' issue you see might occur in relation to changing
details on the LDAP server, which suggests to me that the
sync-during-logon might be at fault here. It would be good to get
confirmation of that.
> An other major problem I have is that the synchronization with the
> iPhone does not work properly anymore: Changes made to existing events
> are synchronized properly, but new events created with Apple iCal are
> not synchronized to an iPhone. Another instance of iCal does receive
> these new events, though. Events added with an iPhone are synchronized
> to the server and appear on instances of iCal, but disappear from the
> iPhone with the next synchronization. Any help appreciated!
Do you have the iPhone set to "Sync All Events"? That seems to be the
current working setting, which is changed from what once used to work
best.
I was recently contacted by an Apple developer and have fixed a bug
(post 0.9.9.5) which he advised me of. That fix will be included in
0.9.9.6 that I was hoping to release this week, but it would also be
good to receive some fixes to the LDAP bugs you're talking about here.
I know a couple of people have been looking at the LDAP plugin recently,
thinking of rewriting it, which would be nice.
> During my testing, the following errors appeared in the error-log
> (don't know if they are related):
> > davical: ***: ERROR:Could not recognize timezone "GMT +0100
> (Standard) / GMT +0200 (Daylight)" - will use floating time
> This error appeared quite often. I think it only appeared since the
> update.
This is more of a warning than an error. DAViCal doesn't really care
about the timezone of an event, passing the event unmodified to the
client. It's more to point out that you have something somewhere
creating odd timezones.
I expect timezone handling to be assisted greatly over the next few
versions by the timezone server implementation which will land in
0.9.9.6 (mostly done now) as we will have a full timezone definitions in
place at that time, including database mechanisms for aliasing and
localisation of timezones.
The next version also adds a simple configuration setting which will let
you manually alias an odd timezone like the one above to a more standard
name like "Europe/Berlin" or something, but I'll try and make that
better in future versions by moving it to a database, and (perhaps) even
providing a centralised point where we can maintain aliases / localised
zone names for everyone.
Cheers,
Andrew.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Men still remember the first kiss after women have forgotten the last.
------------------------------------------------------------------------
> Hello Andrew, hello list,
>
> I have updated my installation of DAViCal to 0.9.9.5 a few days ago
> and have since encountered a few regressions. My setup is based on
> Debian 5 (Lenny) and uses an Active Directory via LDAP as the user
> provider. The users mainly use Apple devices (iOS 4.3, Mac OS X 10.6 +
> 10.7), one uses Evoultion.
>
> Since the update, some of the user-records in the database have been
> updated to become invalid: The fields "active" and "email" in the
> table "usr" has been set to NULL (Should the "active" field really be
> NULLable?). Additionally, the fields "displayname" and
> "default_privileges" of the "principal"-table have been set to NULL.
> Afterwards, those users did neither appear under active nor under
> inactive users in the administration interface. A synchronization of
> the LDAP tree with DAViCal (via the administration interface) did not
> help here. So i modified the "active"-field manually to restore the
> users. I have not yet found out which action triggered this update.
> In a short test, the LDAP-related fix from git (Bug #3409180) did not
> help here, and the problems don't sound exactly related, but if you
> think this fixes the problem I might test it once again.
Hi Philip,
It looks like my LDAP crue let me down here :-)
Unfortunately I don't have an LDAP server myself and nobody has asked me
to provide support for any LDAP-based installations. I've had a few
post-release fixes for LDAP things which were broken in 0.9.9.5 and was
planning to release a 0.9.9.6 with the fixes that have been sent to me
so far, but what you're saying here suggests that there might still be a
few regressions nobody has told me about.
From one problem that was discussed on IRC earlier today it seems like
the 'active/email/???' issue you see might occur in relation to changing
details on the LDAP server, which suggests to me that the
sync-during-logon might be at fault here. It would be good to get
confirmation of that.
> An other major problem I have is that the synchronization with the
> iPhone does not work properly anymore: Changes made to existing events
> are synchronized properly, but new events created with Apple iCal are
> not synchronized to an iPhone. Another instance of iCal does receive
> these new events, though. Events added with an iPhone are synchronized
> to the server and appear on instances of iCal, but disappear from the
> iPhone with the next synchronization. Any help appreciated!
Do you have the iPhone set to "Sync All Events"? That seems to be the
current working setting, which is changed from what once used to work
best.
I was recently contacted by an Apple developer and have fixed a bug
(post 0.9.9.5) which he advised me of. That fix will be included in
0.9.9.6 that I was hoping to release this week, but it would also be
good to receive some fixes to the LDAP bugs you're talking about here.
I know a couple of people have been looking at the LDAP plugin recently,
thinking of rewriting it, which would be nice.
> During my testing, the following errors appeared in the error-log
> (don't know if they are related):
> > davical: ***: ERROR:Could not recognize timezone "GMT +0100
> (Standard) / GMT +0200 (Daylight)" - will use floating time
> This error appeared quite often. I think it only appeared since the
> update.
This is more of a warning than an error. DAViCal doesn't really care
about the timezone of an event, passing the event unmodified to the
client. It's more to point out that you have something somewhere
creating odd timezones.
I expect timezone handling to be assisted greatly over the next few
versions by the timezone server implementation which will land in
0.9.9.6 (mostly done now) as we will have a full timezone definitions in
place at that time, including database mechanisms for aliasing and
localisation of timezones.
The next version also adds a simple configuration setting which will let
you manually alias an odd timezone like the one above to a more standard
name like "Europe/Berlin" or something, but I'll try and make that
better in future versions by moving it to a database, and (perhaps) even
providing a centralised point where we can maintain aliases / localised
zone names for everyone.
Cheers,
Andrew.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Men still remember the first kiss after women have forgotten the last.
------------------------------------------------------------------------
Attached Files:
-
signature.asc (0.82 KB)