Re: [vchkpw] Test FHS patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 aledr wrote: Here it is! Do not worry about the RPM errors at the end, I need to fix It on my spec file. You will need to also package in the vusage daemon. It's basically a requirement for the 5.5 tree. It's just not required when building vpopmail, but that may change. As a result of this log I found a few issues that still need to be resolved, but I'll get em fixed here soon. - -- /* Matt Brookings m...@inter7.com GnuPG Key D9414F70 Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknWHIwACgkQ6QgvSNlBT3AfOQCgpLmrCEiQVIvlrhmrVM2qv/xB /7EAoIJBONYAqgKmjUrPttrLn+adtmo7 =f9pV -END PGP SIGNATURE-
Re: [vchkpw] vpopmail make install should support DESTDIR
On 2009-04-01, at 1306, Matt Brookings wrote: John Simpson wrote: this should make it possible to not require root in order to configure or build the software... or is there some other reason root permissions are required? They are required because currently, the Makefiles want to mkdir and chown, etc. when you're doing a make install, i would expect that. are you saying that the process of compiling the software, even if you're not installing it yet, still creates system-level directories? if this is the case, then the Makefile is broken. and vpopmail has been around long enough that i have trouble believing it's broken that badly, which is why i'm asking the question. does the Makefile actually create system-level directories just to compile the software, even if you don't intend to actually install it on the machine where it's being built? | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ j...@jms1.net | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part !DSPAM:49d68dd032684677597184!
Re: [vchkpw] vpopmail make install should support DESTDIR
On 2009-04-01, at 1356, Manvendra Bhangui wrote: On Wed, Apr 1, 2009 at 9:41 PM, John Simpson j...@jms1.net wrote: the only problem i see at the moment is how the FHS stuff is going to affect where the files are. i want the program to self-adjust to FHS layout or built from source layout automatically, which means i'll need to be able to tell either which layout was used and what the FHS locations are, or if there's an internal list of directories (i.e. parent directory of all mailboxes, location of binary files, location of config files, etc.) i can use, and if those directory locations will be stored in a .h file which can be used by external programs (which would seem to make sense.) all these would be passed as arguments to the configure script. They are stored in the file config.log. Else one can have a shell script which creates a .h file using the options passed to the configure script. Just my 2 cents. i know the mechanism for how configure works. the config.log file is a diagnostic tool, to document what the configure command actually did. it's not used in any further compilation or installation steps. normally the configure command builds a file like config.h, which all of the other source files include. my question was what information is, or will be, available in config.h to tell where the various pieces of the package (i.e. mailbox storage, binaries, configuration info, documentation, etc.) are found, rather than assuming (as we do now) that they will be in the domains, bin, etc, doc, and other fixed-name directories within the home directory of the vpopmail user. assuming this information is there, it would also be useful to the maintainers of other packages which add to vpopmail (such as qmailadmin, and possibly the collection of other web admin front-ends which seem to be springing up recently) if there were a command-line tool to return this information. for example, vsysinfo -d would print the directory where the domains are stored, -i for the include files, -l for the location of libvpopmail.a (or .so, eventually), and my personal favourite, -c would print the actual ./configure command line which was used to configure the software. i guess, more than anything else, i need to sit down and start looking at the new code, rather than pestering everybody with questions. all i need now is free time... | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ j...@jms1.net | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part !DSPAM:49d6926b32689042753631!
Re: [vchkpw] vdelivermail stdout to Dovecot deliver
On Thu, 2009-04-02 at 06:01 -0700, Tom Collins wrote: On Mar 30, 2009, at 7:32 PM, Rick Romero wrote: What I'm trying to work around with this method is to handle user-specific .qmail directives. Dovecot doesn't do that, and that is why I can't full out replace vdelivermail with deliver. What if vpopmail was updated to store a user's .qmail file as domain.com/.qmail-user instead of domain.com/user/.qmail? It seems whatever solution I want to implement has a lot of work involved. In this case it would involve migrating all the existing domain.com/user/.qmail files to domain.com/.qmail-user, and the applications which create/modify them. It's not done through vpopmaild. I think the simplest option is just calling deliver via vdelivermail's existing run_command function (which IMHO does exactly what is needed - it would be exactly the same as calling maildrop via domain.com/user/.qmail), I just have been too busy to really test it. Rick !DSPAM:49d699c132681621912481!
Re: [vchkpw] Further Information for Building RPM for vpopmail
On 2009-04-02, at 1036, Manvendra Bhangui wrote: 2009/4/2 John Simpson j...@jms1.net you DO NOT want these to be setuid root. in fact, you don't want ANY of the binaries to be setuid root, except possibly for vpopmaild, and that only if you want to allow it to create and remove domains- otherwise it can run as the vpopmail user with no ill effects. I have not explored that. Example could be making qmail-newu to be setuid root and making the assign file writeable by vpopmail. it's not just those files... vpopmail also modifies the rcpthosts, morercpthosts, virtualdomains, and users/assign files whenever it adds or deletes domains, and it also needs to be able to run qmail-newmrh if the morercpthosts file was changed. and if users have the ability to create their own custom .qmail files, or to specify lines which end up in those files, you DO NOT want the vpopmail user to have write access to any of qmail's control files. a better idea would be to run vpopmaild as root (if you want to allow it to create or delete domains at all) and use it to process any such requests. i know a few people on this list have mentioned web front- ends which duplicate most or all of qmailadmin's functionality, but do all of their work by sending commands to vpopmaild. But getting the root password or doing ssh root is out of question in my production environment. good idea... i take it one step further: the list of people who have root access (i.e. myself only) is exactly the same as the list of people who are allowed to add or delete domains (also myself only.) which means even vpopmaild doesn't NEED root access, since everything else it does can be done by the vpopmail user. as for compiling in extra password checks and so forth... have you read the documentation for sudo? you can allow certain users to execute certain commands with root permissions, but not give them unfettered root access. the syntax is a bit non-intuitive, but once you understand it, it can be quite powerful. it seems to me this would be a better solution than having to manually add in your own custom patches every time a new version of vpopmail is released. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ j...@jms1.net | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part !DSPAM:49d69f8f32685873613284!
Re: [vchkpw] vpopmail make install should support DESTDIR
On Fri, 2009-04-03 at 18:49 -0400, John Simpson wrote: normally the configure command builds a file like config.h, which all of the other source files include. my question was what information is, or will be, available in config.h to tell where the various pieces of the package (i.e. mailbox storage, binaries, configuration info, documentation, etc.) are found, rather than assuming (as we do now) that they will be in the domains, bin, etc, doc, and other fixed-name directories within the home directory of the vpopmail user. assuming this information is there, it would also be useful to the The information is not there apart from VPOPMAILDIR, QMAILDIR. IMHO one will need to add few AC_DEFINE... statements in configure.in to have all directories (prefix, localstatedir, sysconfdir, libdir, includedir, etc) e.g. to open the configuration file vpopmail.mysql the code does it like this /home/experiments/vpopmail-5.4.27grep vpopmail.mysql *.c vmysql.c:Add error result for unable to read vpopmail.mysql and return it vmysql.c:sprintf(config, %s/etc/%s, VPOPMAILDIR, vpopmail.mysql); /home/experiments/vpopmail-5.4.27 it needs to use SYSCONFDIR to be FHS compliant. !DSPAM:49d6d26732681738714041!
