Re: [vchkpw] recompile or not
On 2005-11-07, at 2354, Tom Collins wrote: One problem is that some programs (including qmailadmin) actually make use of information in the header files to conditionally compile its code. To truly move to a dynamic lib, we need to have any program that links to libvpopmail do so without using vpopmail's config file. It's not as simple as just making the lib dynamic. What if we wrote an external program that chkuser could run instead of having to link to libvpopmail? Would that be a good solution. here's a slightly different idea- instead of an external program that vchkpw calls, how about an external program that the ./configure commands from the other packages could use? look at the mysql_config program which is built as part of mysql. it's not really part of the server, it simply exists to return the data that other programs might need when they are compiled (think of qmail-showctl, but geared more toward the needs of a compiler rather than a human being, although without a specific option it could show all of the options... again, like how mysql_config works.) then think of a vpopmail_config program which works the same way- if run without options it shows a help message which includes all of the data, and if run with an option it would print the actual compiler option that the other package's configure script would need. -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | -- PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] recompile or not
At 05.54 08/11/2005, you wrote: On Nov 7, 2005, at 8:15 AM, Nicholas Harring wrote: Please, please, please don't spread FUD by even implicitly blaming chkuser for this. There's no way to implement chkuser in even a vaguely efficient manner without linking against vpopmail. Vpopmail needs to begin building a shared library, then everybody else can just magically begin using it. This puts the blame squarely where it belongs, on the heads of the developers maintaining vpopmail who completely refuse to integrate shared library support into vpopmail. They've been sent patches, and never offered detailed reasons for refusing to integrate. Please, please, please don't spread FUD by even implicitly blaming the vpopmail developers for this. ;-) I've seen *one* patch for this and, IIRC, it didn't apply cleanly to the current version of vpopmail. I worked on it a bit, and liked the results, but delaying pushing it into the mainstream release. One problem is that some programs (including qmailadmin) actually make use of information in the header files to conditionally compile its code. To truly move to a dynamic lib, we need to have any program that links to libvpopmail do so without using vpopmail's config file. It's not as simple as just making the lib dynamic. What if we wrote an external program that chkuser could run instead of having to link to libvpopmail? Would that be a good solution. Main reason for which I wrote chkuser that way is performance. I don't feel correct to run an external program each time I've to check a sender or a recipient (and I don't like qmail forcing everything new to run on external programs). Another solution could be to spread vpopmail lib into two or more libraries, considering a stable core and added functionalities. As I suppose core changing less frequently, that could help avoiding relinking so often (you could consider as having only the core as shared library). Tonino -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ You don't need a laptop to troubleshoot high-speed Internet: sniffter.com
Re: [vchkpw] recompile or not
tonix (Antonio Nati) wrote: At 05.54 08/11/2005, you wrote: On Nov 7, 2005, at 8:15 AM, Nicholas Harring wrote: Please, please, please don't spread FUD by even implicitly blaming chkuser for this. There's no way to implement chkuser in even a vaguely efficient manner without linking against vpopmail. Vpopmail needs to begin building a shared library, then everybody else can just magically begin using it. This puts the blame squarely where it belongs, on the heads of the developers maintaining vpopmail who completely refuse to integrate shared library support into vpopmail. They've been sent patches, and never offered detailed reasons for refusing to integrate. Please, please, please don't spread FUD by even implicitly blaming the vpopmail developers for this. ;-) I've seen *one* patch for this and, IIRC, it didn't apply cleanly to the current version of vpopmail. I worked on it a bit, and liked the results, but delaying pushing it into the mainstream release. One problem is that some programs (including qmailadmin) actually make use of information in the header files to conditionally compile its code. To truly move to a dynamic lib, we need to have any program that links to libvpopmail do so without using vpopmail's config file. It's not as simple as just making the lib dynamic. What if we wrote an external program that chkuser could run instead of having to link to libvpopmail? Would that be a good solution. Main reason for which I wrote chkuser that way is performance. I don't feel correct to run an external program each time I've to check a sender or a recipient (and I don't like qmail forcing everything new to run on external programs). Another solution could be to spread vpopmail lib into two or more libraries, considering a stable core and added functionalities. As I suppose core changing less frequently, that could help avoiding relinking so often (you could consider as having only the core as shared library). I have rebuilt everything after a vpopmail upgrade/downgrade several times in the last few months. It takes less than five minutes to recompile qmail-smtpd for chkuser. That is because I have to wait for qmail to finish. I sorry but this just doesn't take up a major part of my work week. I don't see the lack of a shared lib as cause for so much turmoil. Some people would still build static linked binarys for performance/stability even if a shared lib was available. Me ;^) DAve
RE: [vchkpw] recompile or not
Please, please, please don't spread FUD by even implicitly blaming the vpopmail developers for this. ;-) I've seen *one* patch for this and, IIRC, it didn't apply cleanly to the current version of vpopmail. I worked on it a bit, and liked the results, but delaying pushing it into the mainstream release. Gee, wonder who's patch that was. And of course it didn't, I maintain that patch internally to my organization, but wasn't willing to do so publicly when it was made quite clear it was going nowhere fast with the vpopmail devs. Besides, I seem to recall this being a 10-15 line patch for the makefile only, which I cooked up in about 20 minutes one afternoon while bored, so don't act like this is some monster task. One problem is that some programs (including qmailadmin) actually make use of information in the header files to conditionally compile its code. To truly move to a dynamic lib, we need to have any program that links to libvpopmail do so without using vpopmail's config file. It's not as simple as just making the lib dynamic. That qmailadmin needs the static libraries is hardly vpopmail's concern, especially for those of us without need for qmailadmin. qmail+chkuser and courier don't need any of this info, and the shared lib just works for both of them. What if we wrote an external program that chkuser could run instead of having to link to libvpopmail? Would that be a good solution. No, it'd actually be horrible. You'd be adding an interface which would need a good bit of sanity checking to avoid opening a security hole, you'd be adding system overhead of fork+exec (admittedly minor, but its potentially done a couple hundred thousand times a day on a moderately busy server), and you'd be adding components for the sake of adding components. I have rebuilt everything after a vpopmail upgrade/downgrade several times in the last few months. It takes less than five minutes to recompile qmail-smtpd for chkuser. That is because I have to wait for qmail to finish. I sorry but this just doesn't take up a major part of my work week. I don't see the lack of a shared lib as cause for so much turmoil. Some people would still build static linked binarys for performance/stability even if a shared lib was available. Me ;^) Anybody who thinks linking statically gets them performance needs to re-evaluate their psychoactive drug regimen. I'm trying to find the email I sent to the list to combat exactly this myth, and while performance wasn't spectacularly better with the shared lib, it was better. I can't imagine how stability could be impacted either, its not like this is experimental new technology or anything. Besides, I doubt you really, genuinely build statically linked binaries, but instead build binaries linked statically against libvpopmail. Cheers, Nick winmail.dat
Re: [vchkpw] recompile or not
Nicholas Harring wrote: Please, please, please don't spread FUD by even implicitly blaming the vpopmail developers for this. ;-) I've seen *one* patch for this and, IIRC, it didn't apply cleanly to the current version of vpopmail. I worked on it a bit, and liked the results, but delaying pushing it into the mainstream release. Gee, wonder who's patch that was. And of course it didn't, I maintain that patch internally to my organization, but wasn't willing to do so publicly when it was made quite clear it was going nowhere fast with the vpopmail devs. Besides, I seem to recall this being a 10-15 line patch for the makefile only, which I cooked up in about 20 minutes one afternoon while bored, so don't act like this is some monster task. One problem is that some programs (including qmailadmin) actually make use of information in the header files to conditionally compile its code. To truly move to a dynamic lib, we need to have any program that links to libvpopmail do so without using vpopmail's config file. It's not as simple as just making the lib dynamic. That qmailadmin needs the static libraries is hardly vpopmail's concern, especially for those of us without need for qmailadmin. qmail+chkuser and courier don't need any of this info, and the shared lib just works for both of them. What if we wrote an external program that chkuser could run instead of having to link to libvpopmail? Would that be a good solution. No, it'd actually be horrible. You'd be adding an interface which would need a good bit of sanity checking to avoid opening a security hole, you'd be adding system overhead of fork+exec (admittedly minor, but its potentially done a couple hundred thousand times a day on a moderately busy server), and you'd be adding components for the sake of adding components. I have rebuilt everything after a vpopmail upgrade/downgrade several times in the last few months. It takes less than five minutes to recompile qmail-smtpd for chkuser. That is because I have to wait for qmail to finish. I sorry but this just doesn't take up a major part of my work week. I don't see the lack of a shared lib as cause for so much turmoil. Some people would still build static linked binarys for performance/stability even if a shared lib was available. Me ;^) Anybody who thinks linking statically gets them performance needs to re-evaluate their psychoactive drug regimen. I'm trying to find the email I sent to the list to combat exactly this myth, and while performance wasn't spectacularly better with the shared lib, it was better. I can't imagine how stability could be impacted either, its not like this is experimental new technology or anything. Besides, I doubt you really, genuinely build statically linked binaries, but instead build binaries linked statically against libvpopmail. Thanks for pointing that out to me. I always love the friendly and helpful advice I get from maillists. I certainly appreciate the people who never address me in a condescending or derogatory manner. Thanks so much for simply correcting my misinformation instead of lowering yourself to becoming rude and insulting. DAve
RE: [vchkpw] recompile or not
Thanks for pointing that out to me. I always love the friendly and helpful advice I get from maillists. I certainly appreciate the people who never address me in a condescending or derogatory manner. Thanks so much for simply correcting my misinformation instead of lowering yourself to becoming rude and insulting. DAve Dave - I apologize if I came across as condescending, it was a failed attempt at humor. I do get a little touchy about this issue since I've tried to present everybody with all of the facts, I've done all of the research anybody suggested. I've never even really gotten disagreement about the benefits of what I'm suggesting, and yet I get nowhere on the project. I never even asked somebody to do the work, I simply asked if people were interested, submitted a patch, responded to suggestions and questions, and then the issue disappeared. When I see the arguments you make, some of which are contradicted by the research I've done, I get a little snippy. Part of this is because I see enough traffic on this list that is simply people asking the same questions that could've been answered by the archives. Nick winmail.dat
Re: [vchkpw] recompile or not
On 2005-11-06, at 2143, Szeki - Inc wrote: Question is: I have to recompile, if I only change some function in vpopmail ? The version remains the same, only for example, logging change from p to v. I really have to recompile courier-atuthlib if I change vpopmail option enable-sql-logging ? i would... if other packages were statically linked with libvpopmail, then if the library changes the other programs need to be at least re- linked. however, since most Makefiles don't have a relink option, your best option is make clean make make install for these other programs. of course, if libvpopmail were a shared library and you had linked courier-authlib to the shared library, then as long as the API hadn't changed you would be okay. but since it does statically link, i would say to re-compile everything that uses libvpopmail. note that if you're using the chkuser patch for qmail, you also need to re-compile qmail as well (which is my biggest objection to the chkuser patch- qmail shouldn't have to be rebuilt every time you upgrade vpopmail.) also be careful- for some programs make clean removes the configuration information and you may have to re-run the ./ configure command again as well. -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | -- PGP.sig Description: This is a digitally signed message part
RE: [vchkpw] recompile or not
of course, if libvpopmail were a shared library and you had linked courier-authlib to the shared library, then as long as the API hadn't changed you would be okay. but since it does statically link, i would say to re-compile everything that uses libvpopmail. note that if you're using the chkuser patch for qmail, you also need to re-compile qmail as well (which is my biggest objection to the chkuser patch- qmail shouldn't have to be rebuilt every time you upgrade vpopmail.) Please, please, please don't spread FUD by even implicitly blaming chkuser for this. There's no way to implement chkuser in even a vaguely efficient manner without linking against vpopmail. Vpopmail needs to begin building a shared library, then everybody else can just magically begin using it. This puts the blame squarely where it belongs, on the heads of the developers maintaining vpopmail who completely refuse to integrate shared library support into vpopmail. They've been sent patches, and never offered detailed reasons for refusing to integrate. Nick
Re: [vchkpw] recompile or not
On 2005-11-07, at 1015, Nicholas Harring wrote: Please, please, please don't spread FUD by even implicitly blaming chkuser for this. i wasn't trying to cast blame anywhere, and if it sounded like i was then i apologize. There's no way to implement chkuser in even a vaguely efficient manner without linking against vpopmail. Vpopmail needs to begin building a shared library, then everybody else can just magically begin using it. This puts the blame squarely where it belongs, on the heads of the developers maintaining vpopmail who completely refuse to integrate shared library support into vpopmail. They've been sent patches, and never offered detailed reasons for refusing to integrate. i understand the problem... however i wasn't aware that they had received patches which would enable building libvpopmail as a shared library. you are right- if they would expose the libvpopmail stuff as a shared library rather than as a static library, that would totally remove one of my two objections to the chkuser patch (the other being that it locks you into vpopmail and doesn't make any provision for other arbitrary authentication schemes, at least not from what i was able to find on the chkuser web site.) my own solution to this was to take the validrcptto patch, change it to use a cdb file, and add the logic needed to properly handle - default aliases. http://qmail.jms1.net/patches/validrcptto.cdb.shtml it works well, but of course it has the down-side that whenever something changes (domains, users, or aliases are added or deleted) the cdb file needs to be rebuilt. my own suggestion for vpopmail would be to include a hook so that it would call an external program whenever a change is made- because right now i'm doing this as a once- per-minute cron job, and the overhead of firing off the cron job is a bit much. -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | -- PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] recompile or not
On Nov 7, 2005, at 8:15 AM, Nicholas Harring wrote: Please, please, please don't spread FUD by even implicitly blaming chkuser for this. There's no way to implement chkuser in even a vaguely efficient manner without linking against vpopmail. Vpopmail needs to begin building a shared library, then everybody else can just magically begin using it. This puts the blame squarely where it belongs, on the heads of the developers maintaining vpopmail who completely refuse to integrate shared library support into vpopmail. They've been sent patches, and never offered detailed reasons for refusing to integrate. Please, please, please don't spread FUD by even implicitly blaming the vpopmail developers for this. ;-) I've seen *one* patch for this and, IIRC, it didn't apply cleanly to the current version of vpopmail. I worked on it a bit, and liked the results, but delaying pushing it into the mainstream release. One problem is that some programs (including qmailadmin) actually make use of information in the header files to conditionally compile its code. To truly move to a dynamic lib, we need to have any program that links to libvpopmail do so without using vpopmail's config file. It's not as simple as just making the lib dynamic. What if we wrote an external program that chkuser could run instead of having to link to libvpopmail? Would that be a good solution. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ You don't need a laptop to troubleshoot high-speed Internet: sniffter.com
[vchkpw] recompile or not
Hello, I have to recompile for exemple qmailadmin, if I install a new vpopmail version. Question is: I have to recompile, if I only change some function in vpopmail ? The version remains the same, only for example, logging change from p to v. I really have to recompile courier-atuthlib if I change vpopmail option enable-sql-logging ? Peter
