Attached is a revision of UPGRADING that would have been clearer for me.
I'm not terribly fond of the "TRACE" section and the "Server Changes"
section, as I think that they could be more-concise simply with a
reference to other documentation (namely the dbmail.conf "man" page),
but since they weren't a problem for me I've left them be. For the
most-part I feel that an UPGRADING document is there to highlight the
changes between this version and any previous version that may prove to
be problematic. I don't think that the details need to be documented
there as long as it is documented elsewhere.
Thanks,
Lee.
On 01/12/2015 02:55 AM, Harald Leithner wrote:
Hi,
good that you managed to upgrade!
About the documentation, I'm pretty sure that Paul excepts every patch
that makes the documentation more clear and better readable for all.
Now you have fresh knowledge of the upgrade process, so it would be
great if you write a new UPGRADING text file and share it with us.
thx
Harald
Am .01.2015, 07:52 Uhr, schrieb Lee Howard <fax...@howardsilvan.com>:
So after weeks of part-time work resolving dependency issues in the
upgrade (primarily with GMime and Glib, but libevent was also a minor
issue) this evening I upgraded from 3.0.2 to 3.2.2.
I did make a backup of the database, but the schema auto-migration
appears to have worked, things are operational, and I do not notice
any ill effects with the database at this point.
(I'm hoping that the efforts of this upgrade result in no more
situations where clients cannot connect to dbmail-imapd and
dbmail-pop3d services. Whether the problem was in dbmail or in GMime
or something else, I don't know. I didn't have any problems after
upgrading only GMime, but I didn't let dbmail-3.0.2 run long-enough
with GMime-2.6.20 to say. Normally I would see one problem every two
weeks or so, but lately it was more-frequent: like once per-week. I
only finished the GMime upgrade on Thursday.)
I quickly hit-upon the dbmail-imapd segfault bug fixed here:
https://github.com/pjstevns/dbmail/commit/edd6179d638d4257d0a669de582f8770370a7364
So, I applied that patch, and it seems to have resolved the crashing
problem.
Upgrade documentation is a concern for me, though...
The UPGRADING document and the sample dbmail.conf file explain that
[dburi] has deprecated [driver], [host], [sqlport], [sqlsocket],
[user], [pass], and [db]. However, no examples are given and no
format syntax is provided. So, it leaves the user guessing. I'm
sure that database URIs are probably standard, and dbmail adheres to
this standard, but it's not stated. I just followed the example in
dbmail-3.2.2/jenkins/Makefile.
A IMAP behavior change from default, login_disabled=no to yes, is not
discussed at all in UPGRADING.
Lastly, the UPGRADING file contains unnecessary information noise. As
it is the user has to read the entire UPGRADING document and
determine which parts apply to their upgrade path. Since this is the
3.2.2 tarball there is no need to explain the upgrade path to 3.0 as
long as you include the full 2.2-to-3.2 path in the explanation.
Nobody is downloading the 3.2.2 tarball in order to perform a
2.2-to-3.0 upgrade.. That information is only relevant so that those
upgrading from 2.2 can try to discern what they need to do. It would
be clearer if the UPGRADING document did not expect the reader to
decipher the noise from the information and merely explain what users
of all previous versions of dbmail would need to do to upgrade and
maintain the same functional behavior.
Thanks,
Lee.
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
For those upgrading from earlier DBMail versions, you may also need
to upgrade other packages upon which DBMail depends.
DBMail 3.2 has the following dependencies...
======================================
* Database: MySQL 5.0 or better, PostgreSQL 8.3+, Sqlite3, Oracle
* Glib: (>= 2.16.0)
* GMime: (>= 2.6.20)
* OpenSSL
* libmhash
* libzdb
* libevent: (>= 2.0.21)
The DBMail database has changed for 3.2 different from 3.0.
However, as of DBMail 3.2 auto-migrations are supported (DBmail 3.2
will migrate the schema automatically on the first use.) So, no
manual migrations are required.
Config Changes
======================================
* MySQL: notice!
A special note to MySQL users: since DBMail 3.0 stores attachments in
single rows, you need to set 'max_allowed_packet' in /etc/mysql/my.cnf
to a value that is larger than the largest email attachment you expect
to support. So if you accept emails upto say 20MB, you should set a
value for 'max_allowed_packet' of no less than 21MB, leaving some room
for network overhead. If you want to be safe: use 1.5 times the max
message size.
* PostgreSQL: notice!
Also a special note to PostgreSQL users: since pg9 has changed the
default for bytea_output in postgresql.conf you must make sure this
config parameter is set to 'escape'. Failing to do so will make it
impossible for DBMail to parse any query results involving bytea
fields. This in turn will break the migration procedure and make
your email inaccessible.
* dbmail.conf:
------------------
DBMail 3.2 now allows you to select the database backend and authentication
module in the config file using the [dburi] setting. Examples:
dburi = sqlite:///home/johndoe/dbmail.sqlite
dburi = mysql://127.0.0.1:3306/dbmail?user=dbmail&password=mypass&charset=utf8
The old database connection parameter fields (driver, host, user, password,
sqlport, sqlsocket, db) are now deprecated.
------------------
The old TRACE_LEVEL is now not used anymore, and
TRACE_SYSLOG/TRACE_STDERR are now deprecated.
Logging has been broken up into 8 logging levels and each level can
be individually turned on or off. The Stderr/log file logs all
entries to stderr or the log file. Syslog logging uses the facility
mail and the logging level of the event for logging. Syslog can then
be configured to log data according to the levels.
Set the log level to the sum of the values next to the levels you
want to record.
1 = Emergency
2 = Alert
4 = Critical
8 = Error
16 = Warning
32 = Notice
64 = Info
128 = Debug
255 = database queries (very verbose)
Examples: 0 = Nothing
31 = Emergency + Alert + Critical + Error + Warning
511 = Everything
FILE_LOGGING_LEVELS = 7
SYSLOG_LOGGING_LEVELS = 31
------------------
The default value for [login_disabled] has changed from "no" to "yes".
If you wish to retain the pre-3.2 behavior you will need to set this
explicitly to "no".
------------------
Server Changes
======================================
Dbmail until 2.2 used a pre-forking server design with a dedicated
connection to the database backend for each forked process. Even with
a hundred or so concurrently connected clients this stretched the
scalability of the database backends.
Starting with version 2.3.3 dbmail has switched to a single process
that uses a event-driven architecture to handle many many concurrent
clients. Where needed a pool of worker threads is used to process
database transactions. Currently, only the IMAP server is multi-
threaded. Database transactions are handled by a single shared
dynamic database connection pool to minimize the number
of overall database connections.
All this means that a number of configuration options are now
redundant. You can remove the following items from dbmail.conf:
NCHILDREN
MAXCHILDREN
MINSPARECHILDREN
MAXSPARECHILDREN
MAXCONNECTS
---
EOF
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
