Re: Dovecot LDAP using custom field to allow users to connect
Hi Martin,
Thanks for your reply, it's works now !!!
Have a good WE.
Best Regards.
Le 07/06/2017 à 13:14, Martin Wheldon a écrit :
Hi Michael,
Just noticed you are using auth_bind_userdn which we don't.
I think you may need to use pass_filter rather than user_filter??
Best Regards
Martin
On 2017-06-07 10:59, Martin Wheldon wrote:
Hi Michael,
We do exactly that see example below:
user_filter =
(&(&(objectClass=ukFirmGhITPerson)(ukFirmGhITAccSubSrvcs=Email)(ukFirmGhITAccLocked=Email-FALSE))(|(uidNumber=%u)(mail=%u)(ukFirmGhITAccMailAlias=%u)))
pass_filter =
(&(&(objectClass=ukFirmGhITPerson)(ukFirmGhITAccSubSrvcs=Email)(ukFirmGhITAccLocked=Email-FALSE))(|(uidNumber=%u)(mail=%u)))
Does it work without the AllowUser section of the search?
Do you get any records back when you do a ldapsearch with your
user_filter search?
Best Regards
Martin
On 2017-06-07 09:48, Michael JOIGNY wrote:
Hi all,
I'd like to know if it's possible to add a custom field when the
authentification is made by users.
My boolean custom field will be for example "AllowUser" (false/true).
I'm trying to do something like that but it's not working :
/user_filter =
(&(objectClass=posixAccount)(uid=%u)(objectClass=myclass)(AllowUser=TRUE))/
This is my dovecot/ldap configuration below :
/*# dovecot.conf*
/
/passdb {//
// driver = ldap//
// args = /etc/dovecot/dovecot-ldap.conf//
//}/
*# dovecot-ldap.conf*
/hosts = myurl:myport//
//dn = cn=myuser,dc=mydomain,dc=com//
//dnpass = //
//a//uth_bind = yes//
//auth_bind_userdn = uid=%u,ou=users,dc=mydomain,dc=com//
//ldap_version = 3//
//base = ou=Users,dc=mydomain,dc=com//
//scope = base//
//default_pass_scheme = SSHA512
/
Do you have an idead ?
Kind regards.
--
Michael
--
Re: [Dovecot] Dovecot stops with "Fatal: kevent(): Invalid argument"
On 05/21/2011 17:54, Timo Sirainen wrote: > On 21.5.2011, at 2.51, Henrik Larsson wrote: > >> That patch doesn't fix anything. It only changes the error message to be more informative so I could figure out what is causing it. If you haven't seen any more errors, it's just a coincidence. >>> >>> I have for some reason not seen the error since applying the above patch. >>> But wouldn't it make sense to include the patch in the stable release so >>> others can give input in the rare case they experience the same issue? At >>> least until the issue has been resolved. >>> >>> I don't say that this is a Dovecot issue, and I admit that it have to be a >>> rare case, but when two independent people experience the same error, there >>> have to be a problem somewhere. >> >> Is there a problem adding a patch like this to the stable code? > > Annoying to add ugly debug code for a problem that happens so rarely.. > >> Should I ask the FreeBSD dovecot2 port maintainer to add it to the FreeBSD >> port instead? > > I wouldn't mind them adding it. > I just saw it (~1500 users affected, dovecot disappeared) dovecot: master: Panic: kevent() failed: Invalid argument FreeBSD 11-RELEASE-p10, dovecot 2.2.29 (.1_2 package revision) This thread was the only exact match on search engines… No other match in last 60 days's logs of our two dovecot 'backends' (nor in last 10 years from my head) Not sure if this can help… a least for stats … @Timo: kudos for ~15 years of not experiencing this kind of bugs :) -- *geoffroy desvernay* C.R.I - Administration systèmes et réseaux Ecole Centrale de Marseille signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Dovecot stops with "Fatal: kevent(): Invalid argument"
I believe this is fixed in the latest ports (2.2.30.2) > On 05/21/2011 17:54, Timo Sirainen wrote: > On 21.5.2011, at 2.51, Henrik > Larsson wrote: > >> That patch doesn't fix > anything. It only changes the error message to be more informative so I could > figure out what is causing it. If you haven't seen any more errors, it's just > a coincidence. >>> >>> I have for some reason not seen the > error since applying the above patch. But wouldn't it make sense to include > the patch in the stable release so others can give input in the rare case > they experience the same issue? At least until the issue has been resolved. > >>> >>> I don't say that this is a Dovecot issue, and I > admit that it have to be a rare case, but when two independent people > experience the same error, there have to be a problem somewhere. >> > >> Is there a problem adding a patch like this to the stable code? > > > Annoying to add ugly debug code for a problem that happens so rarely.. > > >> Should I ask the FreeBSD dovecot2 port maintainer to add it to > the FreeBSD port instead? > > I wouldn't mind them adding it. > I > just saw it (~1500 users affected, dovecot disappeared) dovecot: master: > Panic: kevent() failed: Invalid argument FreeBSD 11-RELEASE-p10, dovecot > 2.2.29 (.1_2 package revision) This thread was the only exact match on search > engines… No other match in last 60 days's logs of our two dovecot 'backends' > (nor in last 10 years from my head) Not sure if this can help… a least for > stats … @Timo: kudos for ~15 years of not experiencing this kind of bugs :) > signature.asc 1K
Re: Minor patches for builds against ancient platforms
"M. Balridge" writes: I assume it's a rarely seen issue because few Dovecot users compile the software in caves on computers powered by horse-pulled generator wheels. I resemble that remark. Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log was locked for 95 seconds (rotating while syncing) Timo recently explained to me it's probably caused by slow I/O or processing. This explanation is consistent with my observation that the users who get these messages have jumbo mailboxes. imap(luser): Error: fchown(/home/luser/mail/.subscriptions.lock, group=501(coregroup)) failed: Operation not permitted (egid=200(users), group based on /home/luser/mail - see http://wiki2.dovecot.org/Errors/ChgrpNoPerm) imap(luser): Error: file_dotlock_open() failed with subscription file /home/luser/mail/.subscriptions: Operation not permitted .subscriptions doesn't exist either as a file or a directory in the named directories. Is there a "filter" against dot-files being opened within the bowels of dovecot? You can disable dotclock altogether, but I don't think this is what you meant. You can use locking method "dotlock_try" rather than "dotlock" -- the former will ignore quota/permissions problems and plow on. (It still logs it.) You could also align luser's mail folder group with with luser's GID, which is usually what I do. Maybe locks are created even when files don't exist as there may be a race condition where another process is creating/deleting it at the same time. Joseph Tam
Re: [Dovecot] Dovecot stops with "Fatal: kevent(): Invalid argument"
On 9 Jun 2017, at 16.29, geoffroy desvernay wrote: > > dovecot: master: Panic: kevent() failed: Invalid argument [EINVAL] The specified time limit or filter is invalid. Because this was the main kevent() call, I think it means that the time limit was invalid. But I wonder what exactly that means. Is it too low or too high? Do you have a core dump you could debug? Would be interesting to see what the value of "ts" is. Or you could try adding the attached patch and if it happens again, it would log ts's value. diff Description: Binary data
Re: Minor patches for builds against ancient platforms
On 9 Jun 2017, at 5.03, M. Balridge wrote: > 1) In src/lib/compat.h there is a definition for p(read|write) that conflicts > with the one in /usr/include/unistd.h > > On this box, there is a macro appended to the definition (to control whether > or not THROW is defined in C++ "mode"). This is regulated by using the macro > __THROW. I assume this is anachronistic. I don't know about this. Anyway, can't apply this patch since it likely fails elsewhere. > 2) There was an odd overflow bug in the quota module. (Yes, would you believe > that user quotas are used + enforced on this Frankenbox?) I assume it's a > rarely seen issue because few Dovecot users compile the software in caves on > computers powered by horse-pulled generator wheels. I suspect Timo's seen > more Abominable Snowcreatures in Espoo than systems like these. > > Simply adding an explicit 64 bit (unsigned) type to the constant multipliers > seemed to address this. Of these two patches, this is probably the most "safe" > and thus likely to be accepted into the main branch of code. Yeah, I'll add that one. Not really sure if that's a generic 32bit problem. Nobody has previously complained about it though. > Thanks for the great software, as always, Timo. It's a testimony to your > design and implementation acumen that software you've written in 2017 still > runs on machines that went obsolete in 480 B.C.E. For a long time Dovecot supported C89 compilers, but nowadays we at least require proper C99 compilers.. > I am trying to track down one possible issue that could be locking-related, > which causes some mailbox open operations to see to take longer than they > should. Log entries like: > >> Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log >> was locked for 95 seconds (rotating while syncing) > >> Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log >> was locked for 92 seconds (rotating while syncing) As Joseph mentioned, this is likely happening because Dovecot is doing a lot of work while keeping the log file locked. The "rotating while syncing" is probably not the real reason. I think it's just doing a lot of work on the mbox file itself (reading/writing/rewriting). Would be nice of course if it logged more information, but mbox format is a bit too legacy to spend much time on improving. > imap(luser): Error: fchown(/home/luser/mail/.subscriptions.lock, > group=501(coregroup)) failed: Operation not permitted (egid=200(users), group > based on /home/luser/mail - see http://wiki2.dovecot.org/Errors/ChgrpNoPerm) > > imap(luser): Error: file_dotlock_open() failed with subscription file > /home/luser/mail/.subscriptions: Operation not permitted > > .subscriptions doesn't exist either as a file or a directory in the named > directories. Client is trying to subscribe, and Dovecot wants to create subscriptions file. Dovecot wants to preserve the group permissions from the /home/luser/mail directory, but it has no permission to set the file's group to "users", so it aborts. You could chmod 0700 /home/luser/mail if possible. > Is there a "filter" against dot-files being opened within the bowels of > dovecot? The problem above isn't dotlock, but rather the file permission preservation in general.
Re: Minor patches for builds against ancient platforms
> >> Warning: Transaction log file > /home/luser/mail/.imap/INBOX/dovecot.index.log > >> was locked for 95 seconds (rotating while syncing) > > Timo recently explained to me it's probably caused by slow I/O or > processing. This explanation is consistent with my observation that > the users who get these messages have jumbo mailboxes. I do know that this little box of horrors has 200-300MB mbox INBOXes on an ext3 filesystem formatted in 2005. I am very nervous about converting them to Maildir at this point. If I could get someone (or something) to the site and replace it with something much more suitable, I could have these people join the 21st Century. > You can disable dotclock altogether, but I don't think this is what you > meant. You can use locking method "dotlock_try" rather than "dotlock" > -- the former will ignore quota/permissions problems and plow on. > (It still logs it.) You could also align luser's mail folder group with > with luser's GID, which is usually what I do. What I meant was, are certain types of filenames "blocked" by policy from being created via IMAP commands? I'm sure I could run a few tests to answer this for myself, or better still, go through Timo's code. > Maybe locks are created even when files don't exist as there may > be a race condition where another process is creating/deleting it at > the same time. Sure, I could see that. In reading through the locking code of sendmail, dovecot, UW-IMAPD, and procmail, it's clear that locking files under UNIX is chaotic and filled with no small amount of voodoo. And naturally, opinions and implementations radically disagree. (How sensible it was of Timo to make it a RUNTIME configuration option in dovecot.) I appreciate your reply, Joseph. 48 hours after switching half of the userbase to dovecot, I am not seeing any serious problems, and already people are more often than not very pleased by the improved performance and responsiveness. One last problem area is that many users have soft-links to mailboxes located on a second drive, but these never appear in folder enumeration lists or they appear grayed out in SeaMonkey/Thunderbird. I've tried just symbolically linking to directories containing other mboxes, but sometimes it works, and sometimes it doesn't. I wonder if there's paranoia checking in the code that follows symbolic links to ensure that uids/gids of the "owning" directory and the linked-to directory (or files within it) are the same. I'm still trying to absorb all of the documentation for dovecot. =M=
Re: Minor patches for builds against ancient platforms
On 06/09/2017 05:13 PM, M. Balridge wrote: > I do know that this little box of horrors has 200-300MB mbox INBOXes on an > ext3 filesystem formatted in 2005. I am very nervous about converting them to > Maildir at this point. If I could get someone (or something) to the site and > replace it with something much more suitable, I could have these people join > the 21st Century. I for one am finding this thread extremely entertaining. I have to wonder how you'd sound if you came across a machine that was actually OLD. ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA
Re: Minor patches for builds against ancient platforms
I do know that this little box of horrors has 200-300MB mbox INBOXes on an ext3 filesystem formatted in 2005. I am very nervous about converting them to Maildir at this point. Fortunately, it just involves reformatting the data and a little reconmfiguration of dovcot. If you can find the tool and disk space, it's well worth doing. Of course, when running a proverbial dinosaur, you're often more preoccupied with preventing the next proverbial meteorite strike. What I meant was, are certain types of filenames "blocked" by policy from being created via IMAP commands? I'm sure I could run a few tests to answer this for myself, or better still, go through Timo's code. I never saw anything that could do that -- maybe you can torture the virtual mailbox facility to get that done. If all your concerned is dovecot dot-files, you can place the indices somewhere else other than the user's filesapace. One last problem area is that many users have soft-links to mailboxes located on a second drive, but these never appear in folder enumeration lists or they appear grayed out in SeaMonkey/Thunderbird. I've tried just symbolically linking to directories containing other mboxes, but sometimes it works, and sometimes it doesn't. I wonder if there's paranoia checking in the code that follows symbolic links to ensure that uids/gids of the "owning" directory and the linked-to directory (or files within it) are the same. It works for me. From what I see, the ownership of the symlink is ignored; it's the underlying file that counts. Maybe a subscription issue? Joseph Tam
Changing the name of a compressed file
Concerning Maildir, the wiki page on compression has this: All mails must have ,S= in their filename where contains the original uncompressed mail size, otherwise there will be problems with quota calculation as well as other potential random failures. Note that if the filename doesn’t contain the ,S= before compression, adding it afterwards changes the base filename and thus the message UID. The safest thing to do is simply to not compress such files. Further down on the same page is this: If the file does exist, rename() (mv) the compressed file over the original file. • Dovecot can now read the file, but to avoid compressing it again on the next run, you'll probably want to rename it again to include e.g. a "Z" flag in the file name to mark that it was compressed (e.g. 1223212411.M907959P17184.host,S=3271:2,SZ). These comments seem to contradict each. Or is there a difference between adding the size specifier to the filename and adding a Z flag to the end of the file name? -- Peter West p...@pbw.id.au And the great throng heard him gladly. signature.asc Description: Message signed with OpenPGP
Re: Changing the name of a compressed file
> On June 10, 2017 at 5:58 AM Peter West wrote: > > > Concerning Maildir, the wiki page on compression has this: > > All mails must have ,S= in their filename where contains the > original uncompressed mail size, otherwise there will be problems with quota > calculation as well as other potential random failures. Note that if the > filename doesn’t contain the ,S= before compression, adding it > afterwards changes the base filename and thus the message UID. The safest > thing to do is simply to not compress such files. > > Further down on the same page is this: > > If the file does exist, rename() (mv) the compressed file over the original > file. > • Dovecot can now read the file, but to avoid compressing it again on > the next run, you'll probably want to rename it again to include e.g. a "Z" > flag in the file name to mark that it was compressed (e.g. > 1223212411.M907959P17184.host,S=3271:2,SZ). > > These comments seem to contradict each. Or is there a difference between > adding the size specifier to the filename and adding a Z flag to the end of > the file name? > > -- > Peter West > p...@pbw.id.au > And the great throng heard him gladly. > Keyword is 'base filename'. From the wiki, "The standard filename definition is: ":2,".". Z is a flag. Aki
