Hi squirrelmail users,
I recently did an update and I wanted to give an overview of the process
involved in (what I think is) updating squirrelmail for a production
environment.
Maybe there are better ways to do this and other users can comment,
share their experiences or give additional information on how they do this.
A list of plugins is available at the end of this email.
ENVIRONMENT DESCRIPTION:
Platform: Debian sarge
Web: apache 1.3.33 and apache-ssl 1.3.33
Mail: postfix, postfix-tls 2.1.5
IMAP: cyrus 2.1.18
E-mail usernames and passwords are stored in a mysql db. I use
web-cyradm for this purpose. Its functionality is ok, but the web user
interface is rather unintuitive, and contains several bugs.
For squirrelmail 1.4.4, I came up with several patches to make things
work the way I wanted them to.
I will try to list any custom change that I made, as I had to reproduce
it in yesterday's upgrade.
PRE 0: BACKUPS, BACKUPS, BACKUPS
Create backups of all squirrelmail directories, the squirrelmail
database, and the mail database.
PRE 1: ADAPT SQUIRRELMAIL TO MY DIRECTORY STRUCTURE / SETUP
Have previously used debian's squirrelmail package, and I liked some of
it's features. Most importantly, configuration files are kept in
/etc/squirrelmail. Steps:
* create new squirrelmail directories as
/usr/share/squirrelmail-1.4.6 and /etc/squirrelmail-1.4.6 so as not to
interfere with running version during installation.
* move "config/*" to /etc/squirrelmail-1.4.6 and create symlink
* hack "conf.pl" to reflect change of location for sqmail, plugin and
themes directory. Otherwise cannot use conf.pl to load plugins.
PRE 2: RUN CONF.PL AND TRANSFER CONFIGURATION SETTINGS
Transfer all configuration settings between the old and the new
config.php. After this is done, run a diff and check to make sure
nothing was missed.
PRE 3: COPY OLD PLUGIN CONFIGURATION FILES OVER TO NEW LOCATION
In my last installation, I would copy every plugin configuration file
over to /etc/squirrelmail/<plugin_name>_config.php, and create a symlink
from the plugin directory. This is nice because when doing an update,
one can remove the plugin directory, extract it, and create the symlink
again, without having to worry to overwrite any files.
# cp /etc/squirrelmail/*_config.php /etc/squirrelmail-1.4.6/
STEP 1: IDENTIFY NEW PLUGINS
I use the plugin updates (pupdate) plugin for this. Unfortunately, this
does not work with all plugins, probably because some of the authors do
not conform to coding guidelines, although I have not looked up the cause.
This identified the following new plugins for my installation:
- SIEVE Mail Filters
* install: 1.9.3
* current: 1.9.6 (DEVEL)
- Change MySQL Password
* install: 3.2
* current: 3.3-1.2
NOTE: a look on squirrelmail.org revealed that the name of the plugin,
it's main features, configuration files etc changed radically
between those two versions.
- Compatibility
* install: 2.0.2
* current: 2.0.4
- JavaScript Clock
* install: 0.6
* current: 0.7
- Unsafe Image Rules
* install: 0.7
* current: 0.8
- VirtualHost Login
* install: 3.6
* current: 3.8.0-1.2.7
STEP 1b: IDENTIFY NEW PLUGINS FOR WHICH THERE IS NO VERSION INFO
- Ask User Info (unchanged)
- Delete Move Next (core)
- List Commands (core)
- Mail Fetch (core)
- Message Details (core)
- Newmail (core)
- To-Do Reminder
- Translate (core)
NOTES:
- "View as HTML" is not shown in the output of the pupdate plugin, maybe
due to my settings? (stable=show, CVS=hide, updated=show,
unofficial=show, core=hide, data files=show, location=hide).
- core plugins are shown even though core is set to "hide".
STEP 2: INSTALL PLUGINS
Go through list (see end of this email). For each plugin:
1) # egrep -ri "patch" *
Apply patch for squirrelmail 1.4.6, if necessary
2) Is there a config file?
Create symlink to /etc/squirrelmail-1.4.6/<plugin>_config.php:
# ln -s /etc/squirrelmail-1.4.6/<plugin>_config.php config.php
3) Check for changes in config file
# diff config.php.sample config.php
4) In most cases, old config files are fine. Create new config
file if necessary, or add a few lines. Whatever takes less time.
5) Is there a custom patch?
If there were problems with a plugin before, and a custom patch
was made for it, apply it.
6) Load Plugin.
NOTES 1: PATCHES PROVIDED WITH PLUGINS
- "compatibility" plugin requires patch of sm source
- "html_mail" plugin: optional patch to sm source
- "image_buttons" plugin requires patch of sm source
- "quicksave" plugin requires patch of sm source, but included patch
fails on 1.4.4 and 1.4.6.
- "multilogin" patch to sm source so can use extended vlogin plugin
functionality.
NOTES 2: CUSTOM PATCHES
- "todo" plugin has a bug where it does not work when calendar plugin is
also installed, because of namespace collision in functions. This
seems particularly silly because the author of "todo" admits to have
modeled his plugin after the "calendar" plugin.
Custom patch just changes function names and resp function calls.
- "quicksave" plugin: custom patch to implement functionality provided
by the included patch that breaks with >= 1.4.4.
- "calendar" plugin has some bugs that relate to its "holiday"
functions. Custom patch removes broken or unfinished holiday
functionality.
- "attach_doc" is not very informative when it comes to pdf conversions.
In some cases the underlying application will refuse to convert on
account of "Copying text [...] not allowed", which gives users a very
cryptic error message. Custom patch provides more user-friendly
response, though it is dirty hack.
- "check_quota" plugin breaks if server is running on non-standard https
port. Custom patch fixes this problem by checking for "securePort"
variable.
- "download_all" plugin. This is rather silly, because author included
file called "ADD THIS HOOK.txt" when he really should have provided
a patch. Custom patch prevents me from having to edit sqmail source
time and again.
STEP 3: HACK db_prefs.php
- This time, created custom patch to extend the default array for db
prefs in db_prefs.php. IMO this should be configurable externally.
STEP 4: FINISH UP AND TEST
- Several small things that relate only to my setup, such as custom
login sites for different SSL virtual hosts, etc
- test new setup
STEP 5: TRANSFER INTO PRODUCTION
- Change links, aliases, or VirtualHost directives, and reload/restart
web server
- remove/rename old files to ensure they are not being used by mistake
in the current configuration.
GENERAL NOTES
- "calendar" plugin should not have the same name as the core plugin.
This breaks upgrades on several distributions, including debian.
Namespace collisions are bad. Maybe the plugin directory can be renamed
without harm, but it should not be distributed as it is.
CONCLUSIONS
Upgrading can be difficult. Dependencies between some plugins require a
number of them be updated at the same time (compatibility ...), and
there are conflicts between other plugins, such as namespace collisions
in function names.
SUGGESTIONS FOR ADMINS
When changing configuration files, leave all the comments there. On an
upgrade, one can more easily "diff" the current config against the new
sample config to see if any changes need to be made.
Installed Plugins
1. translate
2. delete_move_next
3. newmail
4. mail_fetch
5. listcommands
6. message_details
7. notes
8. compatibility
9. todo
10. pupdate
11. autocomplete
12. bounce
13. rewrap
14. templates
15. change_sqlpass
16. html_mail
17. quicksave
18. attachment_doc
19. useracl
20. login_alias
21. archive_mail
22. download_all
23. extract
24. show_headers
25. view_as_html
26. unsafe_image_rules
27. askuserinfo
28. sent_confirmation
29. calendar_sql_backend
30. jsclock
31. show_user_and_ip
32. avelsieve
33. image_buttons
34. vlogin
35. check_quota
36. login_redirect
37. calendar
Available Plugins:
38. abook_take
39. administrator
40. bug_report
41. filters
42. fortune
43. info
44. sent_subfolders
45. spamcop
46. squirrelspell
47. calendar.orig
48. multilogin
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
--
squirrelmail-users mailing list
Posting Guidelines:
http://www.squirrelmail.org/wiki/MailingListPostingGuidelines
List Address: squirrelmail-users@lists.sourceforge.net
List Archives:
http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user
List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
