Alessio Cecchi wrote:
Why not try to understand how to fix them for help developers in resolving
these problems?
That would be awesome. If someone posted a bug fix I'd try to get it
released the next weekend. Unfortunately my current job includes a 3
hour per day commute, so my spare time is very limited. Recovering from
what was almost a big mistake with some real estate has taken most of my
time over the last year. I think I can see the light at the end of the
tunnel... Still it'll be at least a month or more before I can spend
any serious time with vpopmail. I do have the last 1200 messages of
interest from this list to look over when I finally get started.
We could start with the report bugs not resolved that each of us has found in
their configurations.
That would be helpful too. Be sure to specify what back end you are
using! Actually I need to know all of the ./configure options. I'm
sure most of the bugs only happen for certain combinations of options.
(The ones none of the developers use.)
Lampa wrote:
> Domain quotas are other problem (ultra minor for me).
Unless someone can come up with a way to manage domain quotas that
doesn't cripple a server if you enable them on an existing machine with
a number of users you will never see domain quotas come back in
vpopmail. So far the consensus is that it is not possible, and that you
should use unix disk quotas if you must have domain quotas.
> There is not much working domain limits
> (and missing qmailadmin support for it), it lacks of documentation
> (little detailed, meaning, ...). Big problem for me is adding alias
> over vpopmaild - vpopmaild returns error but alias is created.
Which back end. It seems all the developers use cdb, which is pretty
much complete and well tested. MySQL is close. PGSQL kind of works,
but doesn't support many options. I think someone is running on ldap,
but I'm not sure. As far as I know none of the other back ends are
being used, but I do try to keep them with no compile errors. To be
viable a back end will need to have someone who is responsible for the
module. They should be using it and be able to understand the code, or
at least provide good, reproducible bug reports. It would be best if
they could take over supporting the back end code.
> There should be 3(4) user levels: System admin, QmailAdmin admin,
> System expert, (Domain admin - postmaster for each domain) - if i
> understand code
3 levels + expert mode. Any user can be an expert.
basic user - can edit own vacation, forward and password
domain admin - can edit all users / forwards / lists in own domain.
Postmaster is the default domain admin, but postmaster can create a
different domain admin and that user could remove domain admin rights
from postmaster, or even delete the postmaster user.
system admin - can edit all users in all domains, and create and delete
domains.
The levels control what the user can access. Expert mode is designed to
grant the ability to edit .qedit-* files in a text window. Even a basic
user could be granted expert mode, and would be able to type anything
they want into their .qmail file. Use this with care since there is no
unix protection between most vpopmail users. Users without the expert
bit can only edit qmail files through specific functions so vpopmail or
vpopmaild can make sure they are valid.
> About problem http://www.mail-archive.com/vchkpw@inter7.com/msg25601.html
> i solved it look at
> http://www.mail-archive.com/vchkpw@inter7.com/msg26090.html (i don't
> know if it proper solution but i think yes)
I wish I was sure it was a proper fix. I'm worried that there might be
something that needs to know when wait_read() has a problem, and your
fix is hiding it. It should be one of the first things that goes in
once I find time. I plan on going through the 1200 messages in reverse
order, so the latest reports will be handled first.
Rick
!DSPAM:48ec3c7332311063819112!
