John Fawcett via Postfix-users:
> > This may sound like the option that requires 100% robust parsing,
> > but that is not necessarily the case.
> >
> > Pass 1: scan parameter settings in main.cf and master.cf, recureively
> > flatten the content of /file/name in mydestination etc., look
> > for anything that smells like name:stuff, and look inside into
> > pipemap:{...}, unionmap:{...}, and { name:stuff options...},
> > and make a list of hash: and btree: maps in the list. Also
> > maintain a superset of all the possible proxy_read_maps and
> > proxy_write_maps values.
> >
> > Pass 2: intersect the hash: and btree: maps in the result from pass
> > 1 with existing pathnames in the file system.
> >
> > Pass 3: generate recommendations:
> >
> > - A table that exists as /path/to/file and /path/to/file.db
> > should be re-indexed and configured as $default_database_type
> > (it should also match the proxy_read_maps superset)
> >
> > - A table that exists only as /path/to/file.db should be
> > configured as $default_cache_db_type (not re-indexed)
> > (it should also match the proxy_write_maps superset)
> >
> > The output from pass 3 is left up to the administrator.
> >
> > Re-run the tool until it produces no more output.
> >
> > This takes more than a few hundred lines of code but it also
> > does cover more.
>
> I would personally favour this kind of approach than a daemon that needs
> to run permanently afterwards to solve a temporary issue, even if it
> means manual steps to do once off.
It's a trade-off between implementation complexity (bugs), and the level
of pain due to absence of automation.
> In theory the code that parses the config already exists, though
> admittedly maybe not all in one convenient place, else postfix would not
> be able to learn about the files it needs to open at run time.
>
> The search of the configuration could actually be limited to those
> parameters that can accept tables. That may actually be a complication
> though, rather than looking through everything.
At present, parameters that can contain lookup tables are listed
in proxy_{read,write}_maps (these lists are still incomplete). The
way that proxymap uses this information today is imperfect: it does
not discover maptype:mapname embedded in /file/name content (*),
and it does not discover parameter settings in master.cf.
What exists is good enough to delegate password-file/LDAP/SQL lookups
to the proxymap and proxywrite daemons, but it does not provide the
complete coverage that is needed to make recommendations for migration
away from Berkeley DB.
Assuming that the shortcomings can be addressed, it would provide
a source of truth for all tables that need to migrated, whether
that is for an on-line helper daemon or for an off-line tool that
is run only a few times to make suggestions.
Wietse
(*) match lists such as mydestination may contain /file/name in
addition to maptype:mapname and other elements.
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
