> Tomas Kuliavas said: >>>>>>>>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. >>>>>>> >>>>>>> >>>>>>> Wrong. Rule No.1 for Debian - "Don't store custom files in system >>>>>>> directories". /usr/share is used by Debian packages. System upgrade >>>>>>> can override your customizations. It is very unlikely to happen to >>>>>>> /usr/share/squirrelmail-1.4.6, but you still use wrong place to >>>>>>> store >>>>>>> customizations. Use /usr/local or webserver's data directories. >>>>>>> http://www.pathname.com/fhs/ >>>>>> >>>>>> You are right. I know the FHS, and I am aware of this. This is my >>>>>> personal preference, though. I don't claim FHS compliance and, like >>>>>> you >>>>>> said, collision is unlikely with this versioning scheme. >>>>>> >>>>>> >>>>>>>>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. >>>>>>> >>>>>>> >>>>>>> See forced_prefs plugin. >>>>>> Ah, yes. Written by you *g >>>>>> I must have overseen it. >>>>>> >>>>>> Thanks for the suggestion, and for your help with i18n. Composing, >>>>>> and >>>>>> replying to emails in other character sets works fine now. >>>>>> >>>>>> >>>>>> johannes >>>>>> >>>>> Where should the configuration files go then? They are 'local' >>>>> customizations. Should they go in /usr/local/squirrelmail? >>>> >>>> http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION >>>> >>>> -- >>>> Tomas >>> Thanks for the quick response, I was thinking more in terms of the >>> plug-ins, most of which come with their own config.php. Granted they >>> are >>> consistent (each plugin has its own config.php). I guess I'm wondering >>> if >>> there is a mechanism to point to local variants of program files (I had >>> to >>> hack the configtest.php and several of the serversidefilters scripts to >>> get them to work with dovecote and our arrangement of user directories >>> (Maildir which lives in the user's directory rather than a central mail >>> area). >> >> Could you explain your question about 'local variants of program files'? > Sure, I've had to modify several of the scripts in serversidefilters > plugin to deal with how dovecot expects its Maildir directories to be > named and how procmail expects its filters to be written. When I get > finish with the migration to the new server, I'll try to provide a diff. > along with a layout of how our user mail files are arranged. While these > changed files apply to all sites on our server they are LOCAL and the > comments earlier in this message seemed to indicate that they should live > off of /usr/local/sbin vs /usr/share. >>> BTW: I've developed as set a perl scripts to move users from one server >>> to >>> another and convert from mbox to maildir (they are hacks but if someone >>> has a similar problem I could send them over). >> >> mbox2maildir scripts are listed on qmail.org sites. > Thanks, but that script only works part way (for me). I've found I had to > apply a different script to get the individual boxes to convert (the > convert everyting under the Mail directory over missed about half of the > mail boxes or converted them over as empty. I'm using those scripts just > to do the /var/mail/username to Maildir conversion. Actually my > perlscript spends most of its effort to insert a .forward in the old user > location after it creates the new user, move the files over, lock the > /var/mail file and append the old messages and then run the various > conversions. The whole process is complicated because we have a shared > server setup and are moving people, one website at a time to the new box.
work with plugin developers in order to make serversidefilter changes configurable only in config.php file. >>> I still have issues with user preferences going into the new new mysql >>> db. >> >> It is impossible to understand your issues, if you don't provide >> information about them. > Sorry for the confusing word structure. This comment has nothing to do > with SM itself, but rather my internal program to move uses between mbox > and maildir in the process of moving their mail accounts to a new server. > As part of that move I have to dump their preferences out of mysql db on > one server and insert them into another and the code to do this still has > problems if they have selected non-standard sent, trash directories. > Again nothing to do with SM directly except that users may have to > manually re-assign these folders. If you have switched from mbox to maildir, it is possible that delimiter or folder prefix was changed. Plugin can detect modified settings and update them according to changes in your IMAP server structure. -- Tomas ------------------------------------------------------- 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
