Re: [vchkpw] Who can tell me exactly how dir_control works?
Dave Goodrich wrote: Michael Bowe wrote: - Original Message - From: Dave Goodrich [EMAIL PROTECTED] Mark Richardson wrote: snip OK, I'm going to reopen this thread as I have taken a break from the issue to deal with other things. Looking again at my user distribution I see the issue has not changed at all. At my last thread update I was adding users to the u directory, this has not changed. My current distribution is like so, a - 53 b - 19 c - 50 d - 74 e - 11 f - 13 g - 13 h - 120 i - 34 j - 34 k - 33 l - 30 m - 48 n - 34 o - 66 p - 29 q - 37 r - 55 s - 47 t - 54 u - 1034 0 - 62 1 - 69 2 - 76 3 - 72 4 - 66 5 - 70 6 - 69 7 - 60 8 - 72 9 - 66 Yea, u is still getting users added. My dir control table looks like so, | domain tls.net | cur_users 3822 | level_cur 1 | level_max 3 | level_start0 0 | level_start1 0 | level_start2 0 | level_end0 61 | level_end1 61 | level_end2 61 | level_mod0 0 | level_mod1 2 | level_mod2 4 | level_index0 56 | level_index1 8 | level_index2 0 | the_dir u Only the curr_users field and level_index1 field have changed (see older posting below, level_index1 was 0 now is 8). I am running vpopmail-5.4.6 on this machine. I have 5.4.10 with several new changes on my dev server, but I would like to solve this problem first, unless someone can tell me the problem is solved in 5.4.10? So, has anyone seen/fixed this issue? Anyone have a good explanation of just how the dir_control system works? I am about to start deciphering it again and trying to find a solution. Thanks, DAve Note: Read the older message below, but as a refresher, I had no issues when using cdb files. Once I migrated to MySQL backend, dir hashing stopped, though it seems vpopmail knows about the dir_control table as it it properly updating the cur_users field. I have looked at the dir hashing code before in an effort to try and understand it, but not being an expert C programmer, it makes my head spin In the mailing list archives there are many accounts of the type of problem you describe Do you mean http://www.mail-archive.com/vchkpw@inter7.com/msg18604.html This is where I got the idea, change something and see what happens http://www.mail-archive.com/vchkpw@inter7.com/msg05262.html Best explanation yet, but it still doesn't explain what level_modX does, or what level_indexX does. http://www.mail-archive.com/vchkpw@inter7.com/msg04465.html This is the message that made me think getting an answer wouldn't be so hard. This is the other user with the same problem I am experiencing, no solution either. http://www.mail-archive.com/vchkpw@inter7.com/msg16037.html I looked Friday into the largest domain (most users) and found the following, 4500+ users user hash dir 0-9 used user hash dir A-Z used user hash dir a-z, currently in u I believe this means that I have hashed up to 1 level and I am currently in u. The source code says I should have the ability to hash into 0-9, A-Z, a-z, which gives me 61 levels (not 62, start counting at 0) since the level_endX fields all read 61 this makes since to me. So I believe. I should have the following values for this domain. cur_users = 4555 level_cur = 1 # how deep have I hashed already level_max = 3 # how many levels to hash level_start0 = 0 # where to start hashing level_start1 = 0 level_start2 = 0 level_end0 = 61 # how many total dirs to have per level level_end1 = 61 level_end2 = 61 level_mod0 = ? # no idea what this does, currently reads 0 level_mod1 = ? # currently reads 2 level_mod2 = ? # currently reads 4 level_index0 = 56 # how deep have we hashed within the first level level_index1 = 0 level_index2 = 0 the_dir = u # the dir we are currently adding users to If this jogs anyones memory, that would be great. I am going to plug these numbers in and see what happens. If anyone out there with more than 5000 users in a domain could send me the contents of their dir_control table, it would be very very helpful. Thanks, DAve I believe that the large number in the cur_users field comes about because that field is typically 32bit (ie max value 4294967295) and perhaps if the value is 0 and gets 1 subtracted from it incorrectly during the conversion, you end up with numbers wrapping and being displayed in that range). Or maybe there is a part of the code that mixes signed and unsigned integers resulting in that bug? Michael. We figured that was an error, replaced the value and everything continued properly.
Re: [vchkpw] Who can tell me exactly how dir_control works?
Michael Bowe wrote: - Original Message - From: Dave Goodrich [EMAIL PROTECTED] Mark Richardson wrote: snip I have looked at the dir hashing code before in an effort to try and understand it, but not being an expert C programmer, it makes my head spin In the mailing list archives there are many accounts of the type of problem you describe Do you mean http://www.mail-archive.com/[EMAIL PROTECTED]/msg18604.html This is where I got the idea, change something and see what happens http://www.mail-archive.com/[EMAIL PROTECTED]/msg05262.html Best explanation yet, but it still doesn't explain what level_modX does, or what level_indexX does. http://www.mail-archive.com/[EMAIL PROTECTED]/msg04465.html This is the message that made me think getting an answer wouldn't be so hard. This is the other user with the same problem I am experiencing, no solution either. http://www.mail-archive.com/[EMAIL PROTECTED]/msg16037.html I looked Friday into the largest domain (most users) and found the following, 4500+ users user hash dir 0-9 used user hash dir A-Z used user hash dir a-z, currently in u I believe this means that I have hashed up to 1 level and I am currently in u. The source code says I should have the ability to hash into 0-9, A-Z, a-z, which gives me 61 levels (not 62, start counting at 0) since the level_endX fields all read 61 this makes since to me. So I believe. I should have the following values for this domain. cur_users = 4555 level_cur = 1 # how deep have I hashed already level_max = 3 # how many levels to hash level_start0 = 0 # where to start hashing level_start1 = 0 level_start2 = 0 level_end0 = 61 # how many total dirs to have per level level_end1 = 61 level_end2 = 61 level_mod0 = ? # no idea what this does, currently reads 0 level_mod1 = ? # currently reads 2 level_mod2 = ? # currently reads 4 level_index0 = 56 # how deep have we hashed within the first level level_index1 = 0 level_index2 = 0 the_dir = u # the dir we are currently adding users to If this jogs anyones memory, that would be great. I am going to plug these numbers in and see what happens. If anyone out there with more than 5000 users in a domain could send me the contents of their dir_control table, it would be very very helpful. Thanks, DAve I believe that the large number in the cur_users field comes about because that field is typically 32bit (ie max value 4294967295) and perhaps if the value is 0 and gets 1 subtracted from it incorrectly during the conversion, you end up with numbers wrapping and being displayed in that range). Or maybe there is a part of the code that mixes signed and unsigned integers resulting in that bug? Michael. We figured that was an error, replaced the value and everything continued properly.
Re: [vchkpw] Who can tell me exactly how dir_control works?
Dave Goodrich wrote: Michael Bowe wrote: - Original Message - From: Dave Goodrich [EMAIL PROTECTED] Mark Richardson wrote: snip I have looked at the dir hashing code before in an effort to try and understand it, but not being an expert C programmer, it makes my head spin In the mailing list archives there are many accounts of the type of problem you describe Do you mean snip I looked Friday into the largest domain (most users) and found the following, 4500+ users user hash dir 0-9 used user hash dir A-Z used user hash dir a-z, currently in u I believe this means that I have hashed up to 1 level and I am currently in u. The source code says I should have the ability to hash into 0-9, A-Z, a-z, which gives me 61 levels (not 62, start counting at 0) since the level_endX fields all read 61 this makes since to me. So I believe. I should have the following values for this domain. cur_users = 4555 level_cur = 1 # how deep have I hashed already level_max = 3 # how many levels to hash level_start0 = 0 # where to start hashing level_start1 = 0 level_start2 = 0 level_end0 = 61 # how many total dirs to have per level level_end1 = 61 level_end2 = 61 level_mod0 = ? # no idea what this does, currently reads 0 level_mod1 = ? # currently reads 2 level_mod2 = ? # currently reads 4 level_index0 = 56 # how deep have we hashed within the first level level_index1 = 0 level_index2 = 0 the_dir = u # the dir we are currently adding users to Ok, that worked somewhat. We are now creating the users within the proper directory. Hmm, how does vpopmail know when to use a new dir? If my thought on the value of level_indexX is correct, might level_modX tell vpopmail when to create the next dir in line? I will fill that dir u with new users and see if a dir v is created. That should also change level_index0 to 57, I believe. DAve If this jogs anyones memory, that would be great. I am going to plug these numbers in and see what happens. If anyone out there with more than 5000 users in a domain could send me the contents of their dir_control table, it would be very very helpful. Thanks, DAve I believe that the large number in the cur_users field comes about because that field is typically 32bit (ie max value 4294967295) and perhaps if the value is 0 and gets 1 subtracted from it incorrectly during the conversion, you end up with numbers wrapping and being displayed in that range). Or maybe there is a part of the code that mixes signed and unsigned integers resulting in that bug? Michael. We figured that was an error, replaced the value and everything continued properly.
Re: [vchkpw] Who can tell me exactly how dir_control works?
- Original Message - From: Dave Goodrich [EMAIL PROTECTED] Mark Richardson wrote: If your only problem is the user count (lucky you) you can manualy reset the cur_users and it will begin wirking again. Ok now you make me worried... What other things have you run in to because that was my fear anyways: I don't understand why this doesn't work (well it just seems unimplemented in vconvert), so what else will i run into ? I thought the mysql support was pretty stable in vpopmail ? The support for MySQL doesn't seem to be the issue here, just the conversion to using MySQL from cdb at this point. I have looked at the dir hashing code before in an effort to try and understand it, but not being an expert C programmer, it makes my head spin In the mailing list archives there are many accounts of the type of problem you describe I believe that the large number in the cur_users field comes about because that field is typically 32bit (ie max value 4294967295) and perhaps if the value is 0 and gets 1 subtracted from it incorrectly during the conversion, you end up with numbers wrapping and being displayed in that range). Or maybe there is a part of the code that mixes signed and unsigned integers resulting in that bug? Michael.
Re: [vchkpw] Who can tell me exactly how dir_control works?
If your only problem is the user count (lucky you) you can manualy reset the cur_users and it will begin wirking again. Ok now you make me worried... What other things have you run in to because that was my fear anyways: I don't understand why this doesn't work (well it just seems unimplemented in vconvert), so what else will i run into ? I thought the mysql support was pretty stable in vpopmail ? This list is not maintained by any developers that can shed some light on this subject ? Thanx, Mark. On Thursday 05 August 2004 14:59, Dave Goodrich wrote: I found little on the subject in Google, and fewer answers anywhere else. I have resorted to reading source code ( I don't program C ). The closest thing I have found is this, http://www.mail-archive.com/[EMAIL PROTECTED]/msg18607.html Though that URL is not responding for me right now. In a nutshell, try changing the numbers, adding deleting, domains, and see what happens. I am currently counting the conf-splits in my domains and trying to understand what values I need to insert into dir_control. If your only problem is the user count (lucky you) you can manualy reset the cur_users and it will begin wirking again. DAve Mark Richardson wrote: Dave have you already found some more info on this subject ? I have the same problem here (see my post) Mark. On Wednesday 04 August 2004 18:21, Dave Goodrich wrote: qmail 1.03 vpopmail 5.4.0 mysql 3.23.58 We had been using cdb and switched to using mysql auth when we moved our users to a new server. We ran vconvert on the domains and everything appeared to work fine. vpopmail.curr_users loaded with enormous numbers, level_curr loaded as zero. Adding new domains, users changes nothing in the dir_control table. I can manually update the curr_users value and it will then begin to increment properly. I would be willing to manually update the other values, if I knew what they should be and what they did. I can whoop up a quick script to insert the proper values, but how do I determine what they should be? Is there any documentation that explains how this works? At this point I am thinking moving a vpopmail installation is a very bad idea. Thanks, DAve -- Dutch Web Services b.v. James Wattstraat 5 2809 PA Gouda Tel. +31 (0)182-69 40 00 (maandag t/m vrijdag van 09.00 uur t/m 17.30 uur) Fax. +31 (0)182-69 40 51
Re: [vchkpw] Who can tell me exactly how dir_control works?
Mark Richardson wrote: If your only problem is the user count (lucky you) you can manualy reset the cur_users and it will begin wirking again. Ok now you make me worried... What other things have you run in to because that was my fear anyways: I don't understand why this doesn't work (well it just seems unimplemented in vconvert), so what else will i run into ? My only problem has been with dir_control, everything else is working fine. There is a small tool in contrib called vcdir which is supposed to correct the problem and reload the dir_control data from the dir_control files in each domain. I have been unable to get it to compile. NetBSD/Sparc (my ecluster machines) does not have libnsl, and Solaris 8 (my MySQL host) is having problems finding libmysqlclient.a. Maybe if I were a C programmer I would be in better shape. Though, using it might solve my problem, it won't answer my questions about what each field's purpose is. I thought the mysql support was pretty stable in vpopmail ? The support for MySQL doesn't seem to be the issue here, just the conversion to using MySQL from cdb at this point. This list is not maintained by any developers that can shed some light on this subject ? Umm, maybe I am just asking the wrong questions. Does anyone know what each field in the dir_control table is supposed to contain? What is the purpose of level_startX, level_endX, level_modX, level_indexX, the_dir? Thanks, DAve Thanx, Mark. On Thursday 05 August 2004 14:59, Dave Goodrich wrote: I found little on the subject in Google, and fewer answers anywhere else. I have resorted to reading source code ( I don't program C ). The closest thing I have found is this, http://www.mail-archive.com/[EMAIL PROTECTED]/msg18607.html Though that URL is not responding for me right now. In a nutshell, try changing the numbers, adding deleting, domains, and see what happens. I am currently counting the conf-splits in my domains and trying to understand what values I need to insert into dir_control. If your only problem is the user count (lucky you) you can manualy reset the cur_users and it will begin wirking again. DAve Mark Richardson wrote: Dave have you already found some more info on this subject ? I have the same problem here (see my post) Mark. On Wednesday 04 August 2004 18:21, Dave Goodrich wrote: qmail 1.03 vpopmail 5.4.0 mysql 3.23.58 We had been using cdb and switched to using mysql auth when we moved our users to a new server. We ran vconvert on the domains and everything appeared to work fine. vpopmail.curr_users loaded with enormous numbers, level_curr loaded as zero. Adding new domains, users changes nothing in the dir_control table. I can manually update the curr_users value and it will then begin to increment properly. I would be willing to manually update the other values, if I knew what they should be and what they did. I can whoop up a quick script to insert the proper values, but how do I determine what they should be? Is there any documentation that explains how this works? At this point I am thinking moving a vpopmail installation is a very bad idea. Thanks, DAve
Re: [vchkpw] Who can tell me exactly how dir_control works?
Dave have you already found some more info on this subject ? I have the same problem here (see my post) Mark. On Wednesday 04 August 2004 18:21, Dave Goodrich wrote: qmail 1.03 vpopmail 5.4.0 mysql 3.23.58 We had been using cdb and switched to using mysql auth when we moved our users to a new server. We ran vconvert on the domains and everything appeared to work fine. vpopmail.curr_users loaded with enormous numbers, level_curr loaded as zero. Adding new domains, users changes nothing in the dir_control table. I can manually update the curr_users value and it will then begin to increment properly. I would be willing to manually update the other values, if I knew what they should be and what they did. I can whoop up a quick script to insert the proper values, but how do I determine what they should be? Is there any documentation that explains how this works? At this point I am thinking moving a vpopmail installation is a very bad idea. Thanks, DAve -- Dutch Web Services b.v. James Wattstraat 5 2809 PA Gouda Tel. +31 (0)182-69 40 00 (maandag t/m vrijdag van 09.00 uur t/m 17.30 uur) Fax. +31 (0)182-69 40 51
