Squirrelmail doesn't work if Safe_mode is turned on in php's setup. The problem is, that the squirrelmail/index.php is owned by root, but the squirrelmail/data directory and the files in it by apache (because SQmail has to write to this directory). But in safe mode, a script(index.php) can only access files that are owned by the same user as the script. The solution would be to let apache own all the files of SQM. Reproducible: Always Steps to Reproduce: 1.emerge squirrelmail 2.workaround bug# 33466 :) 3.try to login into sqmail (if safe mode is set...) Actual Results: sqmail gives the error: Error opening ../data/default_pref Default preference file not found or not readable!
is this fixed with bug 33466 ?
To fix this, someone needs to update the squirrelmail ebuilds to use the new webapp eclass. Best regards, Stu
Created attachment 30315 [details] rewored squirrelmail ebuild just reworked the ebuild to use webapp.eclass some minor tweaks are still needed.
Stuart: show about commiting webapp.eclass ebuilds with a new SLOT ?
webapp.eclass automatically puts builds into SLOT=${PVR}. That's going to cause us some problems - but that's for another bug ;-) Best regards, Stu
Created attachment 30437 [details] squirrelmail-1.4.2-r5.ebuild
please test this and write your opinion
The only comment I have is about pkg_postinst(). If the user has USE=vhosts enabled, they have to manually run webapp-config to install squirrelmail under the correct host. If you use webapp_postinst in your ebuild to install post-installation instructions, these users will get the instructions when they run webapp-config by hand. Also, webapp-config provides full CONFIG_PROTECT support for config files. The ebuild could install the config file, instead of the user having to do it by hand. Otherwise, it looks good. Best regards, Stu
Can you please test squirrelmail-1.4.2-r5 that is in portage right now. I reqrote it to use the new webapp eclass and waited for bug #48962 to be resolved before committing it... Reassigning this bug to me as I'm the squirrelmail maintainer
ok... I looked through the differences between Martin's and my versions to see if I missed anything, and I see he added index.php and data to the server owned... I missed that, so I've updated my version in portage accordingly... and I also threw data into config so it would be made per vhost. Not revbumping as it is a fairly new ebuild, is marked unstable, is a small tweak, and a version bump will be here shortly to address security bug #49675... but please check that you have 1.4.2-r5 version 1.2 (cvs version in the $Header) when you test it out. Thanks.
Created attachment 30505 [details, diff] still minor tweak
Thanks, Martin. I just committed those changes except for one... Is it really neccessary to have config_default.php and config.php? you could always get the default files by looking in /usr/share/webapps/squirrelmail/1.4.2-r5/htdocs/config
since plugins-config is also moved, the ebuild looks quite good for me
two problems: 1. where is the warning that squirrelmail has moved to /usr/share/webapps? Not until I try `qpkg -l squirrelmail` 2. # emerge squirrelmail <snip> * /usr/share/webapps/squirrelmail/1.4.2-r5/hostroot/icons; skipping * squirrelmail-1.4.2-r5 does not install from * /usr/share/webapps/squirrelmail/1.4.2-r5/hostroot/error; skipping * Linking in required files * Installing from /usr/share/webapps/squirrelmail/1.4.2-r5/htdocs * Install would overwrite existing file /var/www/localhost/htdocs/squirrelmail/po/compilepo Fatal error(s) - aborting * Caching service dependencies... >>> net-mail/squirrelmail-1.4.2-r5 merged. >>> clean: No packages selected for removal. >>> Auto-cleaning packages ... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. Should I be concern with the "Fetal error" above? I have no problem login and read mail.
I believe the "fatal error" was because it tried to install squirrelmail to that location, but you already had a copy there... webapps guys wanty to comment on that... as fot the first comment, I removed it because of Martin's suggestion (see comment #11)
warning could be done in src_unpack but please don't use pkg_postinst()
src_unpack is never called for binary installs, though... pkg_postinstall is where information to the user is displayed.
The warning about not calling webapp_src_install() can't be caught any earlier than webapp_pkg_postinst(). Unless you can suggest a way? The fatal error - as Jeremy said - is because you already have an installation of squirrelmail in /var/www/localhost/squirrelmail. I'm concerned about this fatal error, because portage should have already removed your existing copy before the eclass calls webapp-config. I'll do some testing on this tonight. Squirrelmail hasn't moved to /usr/share/webapps. What goes in /usr/share/webapps is a non-executable master copy, which is cloned using the webapp-config tool. Best regards, Stu
What I did was: I have a working squirrelmail located at /var/www/localhost/squirrelmail (Gentoo Virtual Mail guide). After an update to squirrelmail-1.4.2-r5, I try to login //localhost/squirrelmail/, it throw me a 403 forbidden (because index.php is no longer exist in /var/www/localhost/squirrelmail?). I thought that I missed some warnings so I emerged squirrelmail again and saw the "fetal error". In order to get squirrelmail working again, I created a softlink '/var/www/localhost/mail' point '/usr/share/webapps/squirrelmail/1.4.2-r5/htdocs' and login with //localhost/mail/. I don't know what is the right way after all of these change. May be the docs team will update the guide in the future would help?
That's an interesting solution ;-) The best thing to do is to rename /var/www/localhost/htdocs/squirrelmail to something else, then emerge squirrelmail once more. That should put everything where it needs to be. Note: your Apache document root should be /var/www/localhost/htdocs - and not /var/www/localhost. It's an important difference. There are (and will be more) ebuilds in the tree that expect to install files into other directories under /var/www/localhosts. I agree - we haven't fully understood the impact that webapp-config would have. We'll definitely try and learn for the future. Best regards, Stu
OK. So I renamed /var/www/localhost/htdocs/squirrelmail then emerged squirrelmail again. One thing that I noticed is the new ebuild broke `qpkg`. The ebuild put "stuff" in /var/www/localhost/htdocs but `qpkg -l -nc squirrelmail | grep var` didn't pick it up. Then I try `emerge -C squirrelmail`, as expected, the ebuild doesn't clean '/var/www/localhost/htdocs/squirrelmail' either.
There are no plans to make webapp-config compatible with qpkg. Personally, I'd love to, but there's no way to tell Portage about the files that webapp-config installs, and the Portage team are not supportive of the idea either. Sorry. webapp-config does provide you with some options to see what you have installed, and where you have installed it. See the man page for details. Support for hooking into 'emerge -C' should come with webapp-config v1.8, fingers crossed. Best regards, Stu
Created attachment 31152 [details] 4895-squirrelmail-1.4.3_rc1-r1.log webapp guys, can you check this out... USE=-vhosts Why are we getting that error at the end of the emerge? I had webapp-config-1.6 installed when the previous version was emerged. 1.7 was emerged before this version of squirrelmail.
oh, and FWIW, it doesn't look like the old version was upgraded: (01:48:18 Tue May 11 2004 root@eradicator) /var/www/localhost/htdocs/squirrelmail $ ls -l config total 25 lrwxrwxrwx 1 root root 62 Apr 30 12:50 conf.pl -> /usr/share/webapps/squirrelmail/1.4.2-r5/htdocs/config/conf.pl -rw-r--r-- 1 root root 16751 Apr 30 12:50 config.php -rw-r--r-- 1 root root 191 Apr 30 12:50 config_local.php lrwxrwxrwx 1 root root 64 Apr 30 12:50 index.php -> /usr/share/webapps/squirrelmail/1.4.2-r5/htdocs/config/index.php
Urgh. That's an interesting error to say the least. I've managed to reproduce it locally, and am looking into it right now. Best regards, Stu
Okay, webapp-config 1.8 is now available in portage. This version successfully upgrades squirrelmail locally. Best regards, Stu
alright, this bug is getting closed... the webapp version is up and running and seems to be working out well...
