Re: [vchkpw] segfault vdeluser 5.4.21
On 2007-09-20, at 1236, mlist wrote: Now when I try to delete a user I get a segfault: mail:/home/vpopmail/bin # vdeluser [EMAIL PROTECTED] Segmentation fault first, why would you want to delete a domain's postmaster mailbox? second, i would have thought the vdeluser command, or the vdeluser() function, would refuse to delete a postmaster mailbox... however looking at the code, i see that this is not the case. given that RFC 2821 section 4.5.1 seems to say that it's required, is there ever a valid reason to allow a postmaster mailbox to be deleted? | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
[vchkpw] Re: segfault vdeluser 5.4.21
John Simpson wrote: On 2007-09-20, at 1236, mlist wrote: Now when I try to delete a user I get a segfault: mail:/home/vpopmail/bin # vdeluser [EMAIL PROTECTED] Segmentation fault first, why would you want to delete a domain's postmaster mailbox? second, i would have thought the vdeluser command, or the vdeluser() function, would refuse to delete a postmaster mailbox... however looking at the code, i see that this is not the case. given that RFC 2821 section 4.5.1 seems to say that it's required, is there ever a valid reason to allow a postmaster mailbox to be deleted? Without looking at the RFC, I seem to recall is says that you must accept mail for [EMAIL PROTECTED] That's not the same as having a vpopmail user named postmaster for the example.com domain. However, it seems to me to be pretty perverse to delete the [EMAIL PROTECTED] user, replace it with [EMAIL PROTECTED] and then create an alias [EMAIL PROTECTED] pointing to [EMAIL PROTECTED] !!! R.
Re: [vchkpw] Mysql table
On Sep 20, 2007, at 12:56 PM, Rick Widmer wrote: If I remember right, speed was the reason for separate tables, but testing showed it was not faster. I think the single table works better because all your mail users are accessing the same table, and its indexes so they stay loaded all the time. If you use separate tables it is always thrashing the cache as different files need to be accessed. If we were really looking for speed, we could move to a ng (next generation) table format that was more relational. Provide tools to migrate from the old to the new for those people who only access the data through vpopmail's APIs. Continue to support the old method for people who have home-grown apps that access the data. The domains should be in a table of their own, and the users table should index the domains table. Having an index in the users table on an int (and the resulting size savings) would be measurable. The biggest change would be updating the selects and inserts in the code. Not a huge change -- just a join between the tables. Something to consider, and perhaps discuss further (on this list or vpopmail-devel). -- Tom Collins - [EMAIL PROTECTED] Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/ QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
[vchkpw] 5.4.22 + Qmailadmin...is it going to be fixed ?
Is there any movement to fix 5.4.22 to co-habitate with Qmailadmin ? I'm not in any hurry to try and upgrade again BUT I really like running the latest version if possible ;)
[vchkpw] Re: Mysql table
Tom Collins wrote: On Sep 20, 2007, at 12:56 PM, Rick Widmer wrote: If I remember right, speed was the reason for separate tables, but testing showed it was not faster. I think the single table works better because all your mail users are accessing the same table, and its indexes so they stay loaded all the time. If you use separate tables it is always thrashing the cache as different files need to be accessed. If we were really looking for speed, we could move to a ng (next generation) table format that was more relational. Provide tools to migrate from the old to the new for those people who only access the data through vpopmail's APIs. Continue to support the old method for people who have home-grown apps that access the data. The domains should be in a table of their own, and the users table should index the domains table. Having an index in the users table on an int (and the resulting size savings) would be measurable. The biggest change would be updating the selects and inserts in the code. Not a huge change -- just a join between the tables. Something to consider, and perhaps discuss further (on this list or vpopmail-devel). I understand what you're proposing, but I would suggest that it would add complexity for little gain. Of course, that would need benchmarking to establish which is the faster method. If someone can give me a large dataset, I'm happy to crunch some numbers. R.
[vchkpw] Re: Mysql table
Rick Macdougall wrote: Robin Bowes wrote: Tom Collins wrote: I understand what you're proposing, but I would suggest that it would add complexity for little gain. Of course, that would need benchmarking to establish which is the faster method. If someone can give me a large dataset, I'm happy to crunch some numbers. R. How large ? 5k, 15k, 100k ? What sort of size of database are folk using in the real world? How many users? What's the most common no. of users? R.
Re: [vchkpw] Re: Mysql table
Robin Bowes wrote: Tom Collins wrote: I understand what you're proposing, but I would suggest that it would add complexity for little gain. Of course, that would need benchmarking to establish which is the faster method. If someone can give me a large dataset, I'm happy to crunch some numbers. R. How large ? 5k, 15k, 100k ? Rick
Re: [vchkpw] Re: Mysql table
Robin Bowes wrote: Rick Macdougall wrote: Robin Bowes wrote: Tom Collins wrote: I understand what you're proposing, but I would suggest that it would add complexity for little gain. Of course, that would need benchmarking to establish which is the faster method. If someone can give me a large dataset, I'm happy to crunch some numbers. R. How large ? 5k, 15k, 100k ? What sort of size of database are folk using in the real world? How many users? What's the most common no. of users? R. I'm guessing 200 - 2000 but that's based on the servers I manage for clients (around 20 or so). The biggest installation I manage is around 18k users and I could export that with munged domain names / passwords if you wanted something that big. Rick
[vchkpw] Re: Mysql table
Rick Macdougall wrote: Robin Bowes wrote: What sort of size of database are folk using in the real world? How many users? What's the most common no. of users? R. I'm guessing 200 - 2000 but that's based on the servers I manage for clients (around 20 or so). The biggest installation I manage is around 18k users and I could export that with munged domain names / passwords if you wanted something that big. It's hardly worth bothering with for ~2000 users. The difference in memory/disk use would be minimal. An 18k user table would be interesting. R.
Re: [vchkpw] Re: segfault vdeluser 5.4.21
Robin Bowes wrote: Without looking at the RFC, I seem to recall is says that you must accept mail for [EMAIL PROTECTED] That's not the same as having a vpopmail user named postmaster for the example.com domain. However, it seems to me to be pretty perverse to delete the [EMAIL PROTECTED] user, replace it with [EMAIL PROTECTED] and then create an alias [EMAIL PROTECTED] pointing to [EMAIL PROTECTED] !!! Perverse maybe, but it has been requested, and I see no reason not to allow it. I have also been asked to not automatically create the postmaster user with the domain, that will never happen. Once you have created a domain, you are welcome to screw it up any way you want. (Using the onchange mechanism maybe) On the other hand I do want to make sure the catchall account is never deleted, and may also not allow any address that is the target of an alias within the domain to be deleted. (Much easier to do with a database than a .qmail/cdb back end.) I can't remember, there may be a limit where you can't delete the only administrator in a domain. There should probably also be a limit that you can not delete the user you are logged in as, but that may only be a problem for qmailadmin and vpopmaild.
Re: [vchkpw] 5.4.22 + Qmailadmin...is it going to be fixed ?
Ok great...I'll wait for the official release and test that, thanks for all your work on this. On Fri, 21 Sep 2007 16:33:05 -0600, Rick Widmer [EMAIL PROTECTED] wrote: Allie Daneman wrote: Is there any movement to fix 5.4.22 to co-habitate with Qmailadmin ? I'm not in any hurry to try and upgrade again BUT I really like running the latest version if possible ;) There is a patch for qmailadmin on SourceForge. Its tracker number is [1795973]. On the other hand, this weekend I will release 5.4.23 that backs out the change that caused this problem. I want a stable release that does not require any changes to existing code before the next batch of innovation. Rick
Re: [vchkpw] 5.4.22 + Qmailadmin...is it going to be fixed ?
On Sep 21, 2007, at 3:33 PM, Rick Widmer wrote: There is a patch for qmailadmin on SourceForge. Its tracker number is [1795973]. On the other hand, this weekend I will release 5.4.23 that backs out the change that caused this problem. I want a stable release that does not require any changes to existing code before the next batch of innovation. Thanks for that -- I'm going to try to make a QmailAdmin release, and that patch to QmailAdmin isn't really a proper solution. You'll get compiler errors from the implicit declaration of readuserquota (since it's been removed from the .h). One solution would be to keep readuserquota() as it is, and create a new function to replace it (if that's necessary). -- Tom Collins - [EMAIL PROTECTED] Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/ QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
Re: [vchkpw] Re: Mysql table
I wasn't quite ready for this, but it has been on my list for a long time... since it has come up, let me throw up this database structure for comment. I have reduced the number of tables (in a full installation) and made it relational.- CREATE TABLE Domains( domain_idbigint not null auto_increment, domain char(195), ip_address char(18)NOT NULL DEFAULT '0.0.0.0', maxpopaccounts INT(10) NOT NULL DEFAULT -1, maxaliases INT(10) NOT NULL DEFAULT -1, maxforwards INT(10) NOT NULL DEFAULT -1, maxautorespondersINT(10) NOT NULL DEFAULT -1, maxmailinglists INT(10) NOT NULL DEFAULT -1, diskquotaINT(12) NOT NULL DEFAULT 0, maxmsgcount INT(12) NOT NULL DEFAULT 0, defaultquota INT(12) NOT NULL DEFAULT 0, defaultmaxmsgcount INT(12) NOT NULL DEFAULT 0, disable_pop TINYINT(1) NOT NULL DEFAULT 0, disable_imap TINYINT(1) NOT NULL DEFAULT 0, disable_dialup TINYINT(1) NOT NULL DEFAULT 0, disable_passwordchanging TINYINT(1) NOT NULL DEFAULT 0, disable_webmail TINYINT(1) NOT NULL DEFAULT 0, disable_relayTINYINT(1) NOT NULL DEFAULT 0, disable_smtp TINYINT(1) NOT NULL DEFAULT 0, disable_spamassassin TINYINT(1) NOT NULL DEFAULT 0, delete_spam TINYINT(1) NOT NULL DEFAULT 0, perm_account TINYINT(2) NOT NULL DEFAULT 0, perm_alias TINYINT(2) NOT NULL DEFAULT 0, perm_forward TINYINT(2) NOT NULL DEFAULT 0, perm_autoresponder TINYINT(2) NOT NULL DEFAULT 0, perm_maillistTINYINT(4) NOT NULL DEFAULT 0, perm_quota TINYINT(2) NOT NULL DEFAULT 0, perm_defaultquotaTINYINT(2) NOT NULL DEFAULT 0, cur_usersint, level_curint, level_maxint, level_start0 int, level_start1 int, level_start2 int, level_end0 int, level_end1 int, level_end2 int, level_mod0 int, level_mod1 int, level_mod2 int, level_index0 int, level_index1 int, level_index2 int, the_dir char(160), primary key( domain_id ), unique key( domain ) key( ip_address ), ); CREATE TABLE domain_alias( domain_alias_id bigint not null auto_increment, domain_idbigint not null, aliaschar(195), primary key( domain_alias_id ), foreign key( domain_id ) REFERENCES domains( domain_id ), unique key( alias ) ); CREATE TABLE relay( ip_addr char(18) not null, timestampdatetime, primary key( ip_addr ) ), CREATE TABLE users( user_id bigint not null auto_increment, domain_idbigint not null, name passwd char(40), uid int, flagsint, comment char(48), dir char(160), shellchar(20), passwd char(16), remote_ipchar(18), rate_limit int, active char(1), created datetime, timestampbigint default 0 NOT NULL, primary key( valias_id ), foreign key( domain_id ) REFERENCES domains( domain_id ), unique key ( name, domain_id ) ); CREATE TABLE valias( valias_idbigint not null auto_increment, user_id bigint not null, name char(?), aliaschar(195), primary key( valias_id ), foreign key( user_id ) REFERENCES users( user_id ), unique key( name ) ); I use bigint keys because the last time I looked (admittedly it was a long time ago) if you had 2 bigints at the beginning of a table, and the value in the second one was small, those two fields were bigger than the data overwritten when a record is deleted from the table. This increases the amount of data you can recover until the record gets overwritten. (I have had to recover deleted records the by searching through the database files before...) If this happens, MANY_DOMAINS, CLEAR_PASS and IP_ALIAS_DOMAINS will all go away. If we need to enable/disable clear pass it will be an option in the file where we set the database open info. Also, I want to change query construction from creating defines to building them into strings. I would also like to remove all data base structure changes from the code, and provide a sql script to create the database. The vopomail database user should be able to operate with no more than INSERT, DELETE, UPDATE, and SELECT rights to the database.
Re: [vchkpw] Re: Mysql table
On Sep 21, 2007, at 4:32 PM, Rick Widmer wrote: Comments? I think we'll get better domain alias support if you pull column `domain` out of table `Domains` and add it to the table `domain_alias`. Domain name to domain on the system is a many to one relationship, so the name should be in a separate table. I'm not sure we need to have a master and alias -- the names can all be equal with this setup. I mention it because it reduces lookups to a single query (or at least a simpler query). Instead of needing to check for the domain name in one of two tables, you just check one. Apologies if this SQL has any MySQL-flavored syntax... SELECT `user`.`password`, `user`.`flags` FROM `domain_name`, `domain`, `users` WHERE `domain_name`.`domain_id` = `domain`.`domain_id` AND `user`.`domain_id` = `domain`.`domain_id` AND `domain_name`.`name` = '%s' AND `user`.`name` = '%s' You might even want to have the limits fields go into a separate table, with one entry in that table declared default. That way, domains with default entries can all point to that single row in the limits table. -- Tom Collins - [EMAIL PROTECTED] Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/ QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
