SMF Development > Fixed or Bogus Bugs

SMF 2.0 RC4 unable to download and install new packages [SOLVED]

(1/4) > >>

holodoc:
First of all I am sorry if this issue has been brought to attention before but since I am on a very tight schedule with one of my own projects I am going to simply outline the issue I came across today while trying to install some packages on an upgraded SMF 2.0 RC4.

Environment:
- Apache 2.2.3 (CentOS)
- PHP 5.2.10 (no significant modifications / no Suhosin installed)
- MySQL 5.2
- SMF 2.0 RC4 - plain vanilla RC4 upgraded from SMF 2.0 RC3 with no modifications installed, upgrade performed with the small update package
- The Packages folder has been chmod-ed with 777 permission recursively.

How to reproduce:
1) Upload the required mod package archive through SMF admin panel (Admin -> Packages -> Download Packages -> Upload a Package) [upload is successful]
2) Use the modification installation link presented after the successful package archive upload.

What happens?
The installation process reports the following error:

--- Quote ---You cannot download or install new packages because the Packages directory or one of the files in it are not writable!
--- End quote ---

What is actually supposed to happen?
The modification is supposed to install successfully of course :)

After doing some research in the SMF bug tracker I came up with a bug report for SMF 1.1 that pretty well describes the situation in my case (http://dev.simplemachines.org/mantis/bug_view_advanced_page.php?bug_id=166) 

The report also provides a solution for this problem.

Solution to this problem:
Create a folder called temp inside the Packages folder (Packages/temp) and chmod it to 755. If that doesn't help try chmode-ing it to 775 and lastly 777.

I checked my old SMF 2.0 RC3 dailly file backups but I could not find any trace of a temp folder inside Packages which leads me to believe that perhaps the SMF mod installation routine fails to create such folder or at least give a more informative description about whats actually going on - perhaps even check if temp folder actually exists.

Once again I am sorry if a similar SMF 2.0 related bug report exists and I hope that at least the provided solution solves the same problem for other SMF users.

N. N.:
Thank you for the report. Indeed every once in the while this comes up on Support forums, and SMF could probably provide a more informative message at least - if it cannot do something else.

I believe that normally, SMF should create the folder, but delete it after installing, I'm not sure it can (should) be found any other time or place than /Packages during installation of the mod. :)

holodoc:
I've done some further check-ups and it seems to me that SMF actually doesn't even try to remove the temp folder after the whole installation process is over (no log complaints although all folders are highly permissive). In other words whatever modification is installed its files remain inside the temp folder after the whole installation process is over.

Either way I have a question and perhaps a proposal you could consider for one of your next SMF updates (perhaps even SMF 2.0 Final). My question is if it wouldn't be much better to use the standard system /temp folder to store the mod installation files instead of storing them in a rather unpredictable home folder environment.

You see, on Unix/Linux based systems the /temp folder is always present and allows full access to all users while on Windows based machines privileges are something not to worry about since if a requested folder doesn't exist there is no fuss about creating one. Now there is an additional reason why I usually use the system /temp folder in my applications to store non-critical information. Its the fact that in shared hosting environments, which are very common, its not unusual for Apache to run under a separate user which doesn't have required privileges to create folders inside the users home folder (folders are usually set to 0755). That also usually means chmod-ing the whole Packages folder to 777 or at least temporarily changing ownership of the folders to Apache in order for it to be able to write inside these folders. I do realize that changing permissions to 777 for some folders like cache, attachments etc. is inevitable but since you already have reports about this particular problem you might want to reconsider eliminating it by taking a different approach with the system wide /temp folder :)

I do hope that I explained my proposal well enough and that you will at least take it into consideration although I have a feeling that you might have already talked about this :)

Qapla'!

Oya:
but surely the systemwide temp folder is similarly locked down on most shared hosts, and where it's not, there's an implicit security risk from other users on the same host being able to get files in?

Kindred:
if you are on a shared host, you can not get to the system temp folder, as Oya points out.

and, BTW: If a windows server has permissions correctly set, there could indeed be a problem with creating files or folders...

Navigation

[0] Message Index

[#] Next page