In some email I received from "Matthew T. O'Connor" <[email protected]> on Tue, 17 Jun 2003 22:13:10 -0400 (EDT), wrote:
> Right, and if a new user got assigned the id of an old user then all of > the old users data would be exposed to the new user. I understand this > shouldn't happen under normal circumstances but that is the consequence if > it happens somehow. > > As for using foreign keys to do the delete work for you, I agree that I > don't want to mistakenly delete everything and that I do want to be warned > before it does anything. I think the maintenance program that removes the > account should check to see if the user exists, if there are any messages > etc and then warn the person running the script that they are about to > delete an account that still has X mailboxes and Y messages etc, and ask > for confirmation. Furthermore you could prompt for a second confirmation > after doing the delete and rollback the transaction if the admin denies > the second confirmation. > > I agree that the tools should work to prevent you from shooting yourself > in the foot, but I think the database should do as much as it can to keep > itself consistent. I know we have a maintenance script that helps with > these issues, but that is treating the symptom, not fixing the problem. > Right, I've had problems deleting stuff by mistake and after that I had to play with a hex editor to relink/restore a 10gb file system which was A pain, so for dbmail i did something simple, before dbmail-maintenance deletes all the data it asks the user: do you want to save user's old data?!: y/n, say y and you'll get a dump of everything that is somehow related to this user - %user-%date.sql. But I think the best and the safest is to do dump before deletion by default, and have a switch which force it not to:) cheers > > Correct, the new user will be assigned a new id number, despite having > > the same user name. Since the messages are linked by id number rather > > than name, the new user doesn't see the messages which used to belong to > > the old user of the same name. > > > > As for the old messages, I believe that dbmail-maintenance will delete > > them for being unconnected, and so the space will be reclaimed anyhow. I > > believe that the major issue here is that there are any number of > > situation / administrators who wouldn't want to delete a user if they > > still had mail in their account, either because they don't want to face > > killer typos (ie. same reason many people alias mv, cp and rm with -i) > > or because you might want to expire a large number of older accounts, > > but keep the ones that are still being used actively (although there are > > other better ways to do this, I believe in having tools that aid in > > consistency as much as having administrators adhere to consistent > > policy). > > > > Aaron > > > > > > On Tue, 17 Jun 2003, Jacques Beaudoin wrote: > > > >> After doing some test. > >> > >> I think that if you delete a user that as messages in the tables and > >> recreate that user the newly recreate user will not se is old > >> messages. > >> > >> So why be so fussy about deleting messages that belongs to nobody. > >> > >> Jacques > >> > >> > >> Aaron Stone a écrit : > >> > >> > On the other hand, it wouldn't take a lot of code or any significant > >> overhead to run a few queries to see what the user has in the > >> database. Further, I believe that in a data-destroying operation > >> like this, there should be a warning message by default and a > >> --force option if you really don't want to hear about it ;-) > >> > > >> > Aaron > >> > > >> > On Tue, 17 Jun 2003, Matthew T. O'Connor wrote: > >> > > >> > > > If i delete a user is aliases are not deleted thats not a big > >> problem i just delete via a script is aliases (dbmail-aduser c > >> user -a aliases) before i delete that user. > >> > > > > >> > > > But what about is old mailboxes and messages in the > >> > > > mailboxes, messages, messageblks tables. > >> > > > >> > > I would think this is best handled via referential integrity from > >> the database. I added all the foreign key relationships that seem > >> relevant to > >> > > my postgres setup, this guarantees that everthing associated with > >> the > >> > > user gets deleted when the user is deleted (or won't let you > >> delete the user while there is data dependentand on the user, > >> depending on how the foreign key was setup). > >> > > > >> > > > >> > > _______________________________________________ > >> > > Dbmail mailing list > >> > > [email protected] > >> > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > >> > > > >> > _______________________________________________ > >> > Dbmail mailing list > >> > [email protected] > >> > https://mailman.fastxs.nl/mailman/listinfo/dbmail > >> > >> _______________________________________________ > >> Dbmail mailing list > >> [email protected] > >> https://mailman.fastxs.nl/mailman/listinfo/dbmail > >> > > _______________________________________________ > > Dbmail mailing list > > [email protected] > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > _______________________________________________ > Dbmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail > -- Lou Kamenov / Network Infrastructure/Security Analyst AEYE R&D - http://www.aeye.net [EMAIL PROTECTED] AEYE Technologies - http://www.aeyetech.co.uk [EMAIL PROTECTED] phone: +44 (0) 20 8879 9832 fax: +44 (0) 7092 129079 mobile: +44 (0) 79 3945 3026 PGP Key ID - 0xA297084A AEYE(=AI) stands for Artificial Intelligence.
