While I have not looked at the new code releases, I do know that previously
the vpopmail directory was defined in config.h and used for pop and smtp based
on that. Vadddomain also knew to use that same path as well. I'm sure it could
be modified to look anywhere with minimal effort...perhaps have it get the
value from /var/qmail/users/assign for the path instead of pre-defining it at
compile time. This seems to me a far more flexible way to accomplish what your
asking, however could add some latency as it did the lookup each delivery or
pop3 check.
For the short term, you can always put the directories on any disk
volume/partition you want and symlink them back to the /export/vpopmail/domains
directory. While not the most appealing solution, it is stable.
Right now I have my maildirs on an external scsi attached raid. I have the
OS on it's own drive, and the queue itself on another fast scsi drive.
Regards,
--
Stephen Comoletti
Systems Administrator
Delanet, Inc. http://www.delanet.com
ph: (302) 326-5800 fax: (302) 326-5802
"Michael T. Babcock" wrote:
> Yes, it would most likely be better to have multiple drives set up on a fast
> channel controller handling different domains / subsets of domains.
>
> Incidentally, if you change the directory vpopmail uses for the domain, are
> there any inherent bugs (software that doesn't ask vpopmail where the
> maildirs are, etc.)??
>
> /var/vpopmail/01/domain1
> /var/vpopmail/01/domain2
> /var/vpopmail/01/domain3
> /var/vpopmail/02/domain1
> /var/vpopmail/02/domain2
> /var/vpopmail/02/domain3
>
> This would let you mount /var/vpopmail/01 on one drive, and /var/vpopmail/02
> on another.
>
> ----- Original Message -----
> From: "Delanet Administration" <[EMAIL PROTECTED]>
>
> > IMHO, I'd worry more about I/O than disk space. Having a large slow ide
> may
> > hurt more than a fast scsi.
S/MIME Cryptographic Signature
