Zikula Community

Guys guys guys
I hope someone out there has had this problem or atleast seen it, and can offer some help.

The problem I am having is installing PostNuke on my Fedora Core 3 system. I get to the point where it checks the file permissions and if just fails. I set the file permission to the recommended ones. And on top of that I tried changing the onwer of the directories. Still no joy. The respective directories are owned by apache and now all have perms of 777. Still my PostNuke is not seeing them as writable. I know the problem is not in PostNuke. Either some security feature in httpd or PHP because this is not the only PHP application that is having this problem.

Please help guys.

Same configuration, same problem. I put 777 on all I could but PostNuke doesnt see it.
Expert advice :idea: , please.

I must say, I think Fedora Core 3 is crap. I can't get any info on this. I think it possibly has something to do with either the way they have compiled PHP4 or something in the ini file that is making it not work. I suspect they were trying to make PHP more secure and ended up breaking it.

True, true ...
I just commented the chmod part of install script and moved on.
"Live is too short".

Working fine on my site, currently under FC3, formerly under FC2. I never saw this sort of behavior.

Good for you... Hmm... Did you upgrade FC2 to FC3 or made a fresh install?

Mind over matter!

Owner and group for "-R www" have to be 'apache'!

Kind regards!

Both. :)

I had FC2 upgraded to FC3 and everything was fine. Then I built a new system with a fresh install of FC3.

Are you using SELinux? (I'm not.) It could be that has security settings too high, or like you said some default setting in php.ini is messing you up.

Yes!
I had this exact problem.. easy solution though listed at http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2825232
One method is to use system-config-securitylevel to change the policy
and set the file system to relabel.

Following is the manual procedure:

1. Edit /etc/selinux/config and change the type of policy to
SELINUXTYPE=policyname.
2. To ensure that you can return from a reboot, set the mode
to SELINUX=permissive. This way SELinux will be running under the
correct policy, but will let you login if there is a problem such as
incorrect file context labeling.
3. Tell the init scripts to relabel the system on reboot with
the command touch /.autorelabel.
4. Reboot the system. A clean restart under the new policy
allows all system processes to be started in the proper context, and
reveals any problems in the policy change.
5. Confirm your changes took effect with the command sestatus
-v. With the new system running in permissive mode, check
/var/log/messages for avc: denied messages. These may indicate a
problem that needs to be solved for the system to run without trouble
under the new policy.
6. When you are satisfied that the system runs stable under
the new policy, enable enforcing by changing SELINUX=enforcing. You
can either reboot or run setenforce 1 to turn enforcing on in real
time.
now I need to find my original post and post this as my solution.
amazing how easy the solution was after being so frustrated.