[SOGo] Merging diverged databases
Hello, I've noticed that during my vacation our (master-master) database replication failed (for unrelated reasons), and now our SOGo databases have diverged quite a bit between the servers. The good news is that each user exclusively wrote to *one* server, and both servers have used correct autoincrement values, so there shouldn't be any conflicts. What's the best strategy here to merge the databases? Use sogo-backup for each user on the correct server, and then restore on a pristine database? Or can I just merge the databases directly? -- Mit freundlichen Grüßen, / Best Regards, Sven Schwedas Systemadministrator TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167 http://software.tao.at signature.asc Description: OpenPGP digital signature
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
Is there seriously no one here willing to just answer this very simple
question?
On 7/21/2014 8:50 AM, Charles Marcus cmar...@media-brokers.com wrote:
On 7/21/2014 5:42 AM, Christian Mack christian.m...@uni-konstanz.de
wrote:
You can specify multiple SOGoUserSources and set canAuthenticate and
isAddressBook for each according to your needs
Hi Christian,
My apologies to the OP, but I have a question about this very thing.
We have two SOGoUserSources defined in our config.
The first is our linux/sql based email userDB, and does all user AUTH.
The second is an LDAP based user source pointed at our existing
Windows Active Directory DC, and is defined so we can utilize our AD
based Users and Security Groups for controlling access to shared
Calendars and Contacts. The only other options - add each user
separately to every shared resource, or pay for developing an SQL
based Group support - were not workable (although we may eventually
pay to add SQL based Group support).
As I reported a couple of weeks ago, I am having a problem with my
logs being flooded with errors, which I think caused a major problem
once where my sql server blocked the sogo server due to too many
errors. Doubling the number of errors from 10 to 20 appears to have
solved that problem (sogo server hasn't been blocked again... yet),
but the errors flooding the logs continues.
I've narrowed it down to what I believe could be a problem with this
dual config.
The error flood (anywhere from a couple hundred to over a thousand
lines, all with the exact same date/time stamp down to the second),
*always* start with a failed BIND operation, like this:
Jul 21 06:57:07 sogod [29455]: |SOGo| starting method 'REPORT' on
uri '/SOGo/dav/username/Calendar/5EDA-533EC400-A3-564CA400/'
Jul 21 06:57:07 sogod [29455]: 0x0x7ff375997e80[LDAPSource]
NSException: 0x7ff375e48710 NAME:LDAPException REASON:operation bind
failed: Invalid credentials (0x31) INFO:{login =
cn=username,dc=sub,dc=example,dc=com; }
These two lines are then followed by anywhere from hundreds to over a
thousand lines - again, with the exact same date/time stamp down to
the second (this simply cannot be good for performance) - like:
Jul 21 06:57:07 sogod [29455]: [ERROR]
0x0x7ff375e55800[NGLdapAttribute] could not convert value of
objectGUID to string
Jul 21 06:57:07 sogod [29455]: [ERROR]
0x0x7ff375e43760[NGLdapAttribute] could not convert value of
objectSid to string
Jul 21 06:57:07 sogod [29455]: [ERROR]
0x0x7ff375df7130[NGLdapAttribute] could not convert value of
logonHours to string
Jul 21 06:57:07 sogod [29455]: [ERROR]
0x0x7ff375e73880[NGLdapAttribute] could not convert value of
userCertificate to string
They are always the same detail (objectSid, objectGUID, logonHours and
userCertificate), although the [29455] (I assume that is the process
ID?) does have maybe 4 or 5 different values interspersed throughout
these lines.
My question is, could this problem simply be caused because the LDAP
user Source has canAuthenticate set to yes? Or is this required for
the LDAP source to simply be able to be read when applying the ACLs?
I've been hesitant to test this theory on my production system, and
have been meaning to try to get a test environment set up, but I'm a
one man IT support shop, and I'm a bit outside my comfort zone. I paid
Inverse to get this installed and working, but my support hours ran
out before I even realized this problem existed. I'm waiting for
approval from the boss to buy some more support hours so I can get so
I can get some help, but would really appreciate if you could give me
an opinion about this...
Thanks... here are my current user sources:
SOGoUserSources =
(
{
type = sql;
id = directory;
viewURL =
mysql://sogo_user:passw...@sub.example.com:3306/auth_db/sogo_auth;
canAuthenticate = YES;
isAddressBook = NO;
userPasswordAlgorithm = crypt;
},
{
type = ldap;
CNFieldName = cn;
IDFieldName = cn;
UIDFieldName = sAMAccountName;
baseDN = DC=sub,DC=example,DC=com;
bindDN = cn=ldap
lookups,ou=Services,ou=Our_Users,dc=sub,dc=example,dc=com;
bindPassword = readonly-password;
canAuthenticate = YES;
displayName = Our Groups;
hostname = ldap://123.456.100.10:389;;
id = our_groups;
isAddressBook = NO;
scope = SUB;
}
);
So... can I simply change 'canAuthenticate = YES;' for the ldap source
to NO and fix these log flood errors? Or will the users access to the
Shared Calendars/Address Books be broken if I do this?
And maybe would I also need to change 'isAddressBook = NO;' to YES?
Anyway, thanks very much for any advice you or anyone else can offer...
--
users@sogo.nu
https://inverse.ca/sogo/lists
[SOGo] OT? Configuring spamd
I have a spamd process running on our Ubuntu based SOGo server, but I can't find the place where the config files are located. I've edited local.cf in /etc/spamassassin, but the changes didn't appear to do anything (added * SPAM ** to the subject, and turned on a few flags). I occasionally see the spamd show up in top, but I'm not sure what it's doing. We get more spam than I think we should, including some that should easily be blocked based on character matching. I also used to use something called Fuzzy OCR to block image spam, so once I find the place to tweak, I'd like to install that also. Thanks.-- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
Well, I can tell you that the errors below are considered 'normal'. Appearently we all have them, they have been reported on list, and they are harmless. For the rest I cannot help you, I'm sorry. On 7/22/2014 13:21, Charles Marcus wrote: could not convert value of userCertificate to string -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
On 7/22/2014 11:32 AM, heupink heup...@gmail.com wrote:
Well, I can tell you that the errors below are considered 'normal'.
Apparently we all have them, they have been reported on list, and they
are harmless.
Even this one:
Jul 21 06:57:07 sogod [29455]: 0x0x7ff375997e80[LDAPSource] NSException:
0x7ff375e48710 NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31)
INFO:{login = cn=username,dc=sub,dc=example,dc=com; }
?
--
users@sogo.nu
https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
Oh, sorry, missed that you were just referring to the one about the userCert... and thanks for the reply, you're the only one so far, not sure why the devs are ignoring me. Maybe my pleasant demeanor... ;) I'm mostly concerned about the failed bind operation, and the fact that there are literally hundreds up to a thousand or more that happen all within a single second... Like I said, this cannot be good for performance. On 7/22/2014 11:32 AM, heupink heup...@gmail.com wrote: Well, I can tell you that the errors below are considered 'normal'. Appearently we all have them, they have been reported on list, and they are harmless. For the rest I cannot help you, I'm sorry. On 7/22/2014 13:21, Charles Marcus wrote: could not convert value of userCertificate to string -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Question regarding SOGo scalability
On 2014-07-21, 1:46 PM, Rodrigo Habib Gregori wrote: We wonder if SOGo can handle such a user base of this size (actually the base is going to increase: probably 12.000 mailboxes - at least - in 2 or 3 years). Quite easily. At Inverse we support tons of environments with user bases ranging from 25 mailboxes to more than 1 million. Most of our clients have about ~25 000 mailboxes. When configured properly, SOGo will likely never be the bottleneck. You'll have to make sure subsystems like your IMAP and database server can sustain the load. -- Ludovic Marcotte lmarco...@inverse.ca :: +1.514.755.3630 :: http://inverse.ca Inverse inc. :: Leaders behind SOGo (http://sogo.nu) and PacketFence (http://packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
On 2014-07-21, 8:50 AM, Charles Marcus wrote: My question is, could this problem simply be caused because the LDAP user Source has canAuthenticate set to yes? Yes and it's required for groups, as stated in the documentation: /Finally, SOGo supports LDAP-based groups. Groups must be defined like any other // //authentication sources (ie., canAuthenticate must be set to YES and a group must have a valid// //email address)/ You get failures because SOGo tries both sources - as it doesn't know in which one the user will be. The / Jul 21 06:57:07 sogod [29455]: [ERROR] 0x0x7ff375e55800[NGLdapAttribute] could not convert value of objectGUID to string/ warning is harmless and just annoying. It has been silenced and it'll be part of v2.2.7. -- Ludovic Marcotte lmarco...@inverse.ca :: +1.514.755.3630 :: http://inverse.ca Inverse inc. :: Leaders behind SOGo (http://sogo.nu) and PacketFence (http://packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
On 7/22/2014 4:15 PM, Ludovic Marcotte lmarco...@inverse.ca wrote: On 2014-07-21, 8:50 AM, Charles Marcus wrote: My question is, could this problem simply be caused because the LDAP user Source has canAuthenticate set to yes? Yes and it's required for groups, as stated in the documentation: Finally, SOGo supports LDAP-based groups. Groups must be defined like any other authentication sources (ie., canAuthenticate must be set to YES and a group must have a valid email address) Thanks Ludo. I do remember this, but... I also told you when you set this up for me that not one of my Groups have valid email addresses (totally no need for them), and it is working... so... ? You get failures because SOGo tries both sources - as it doesn't know in which one the user will be. Is there an enhancement request to provide a fix for this? Seems like it would be beneficial to others to have a way to check for LDAP Group Membership solely for purposes of applying ACLs... The / Jul 21 06:57:07 sogod [29455]: [ERROR] 0x0x7ff375e55800[NGLdapAttribute] could not convert value of objectGUID to string/ warning is harmless and just annoying. It has been silenced and it'll be part of v2.2.7. All of these error types (ObjectGUID, objectSis, userCert, etc)? Also, can you comment on the fact that there are many *hundreds*, sometimes even over a *thousand*, of these, all in the space of a single second of time? Glad to hear that at least some of these will be silenced soon... It makes trying to read the logs extremely frustrating at times. Thanks again for replying, Charles -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] BTS activities for Tuesday, July 22 2014
Title: BTS activities for Tuesday, July 22 2014 BTS Activities Home page: http://www.sogo.nu/bugs Project: SOGo For the period covering: Tuesday, July 22 2014 idlast updatestatus (resolution)categorysummary 2571 2014-07-22 10:49:50 updated (open) SOGo Connector URLs don't match error when URI contains '@'-char (Thunderbird Connector) 2868 2014-07-22 06:22:02 updated (open) Backend Calendar Moving events between calendars 2867 2014-07-22 06:14:13 updated (open) Backend General ACL caching with LDAP Groups 2866 2014-07-22 04:27:49 updated (open) SOPE custom authentication scheme not handles properly
