HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


5.0.2(beta) problems

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#63525 (In Topic #13747)
Avatar

Community saint

Problem-1

Used the ocPortal toolset, incrementally, and ended up zapping my site without knowing how.

When running the Template cache I got this:


I then started getting '500 - Internal Server Error' for any page I called up on the site. Contacted hosts who went through a few cursory checks to inform me that their suPHP (is that suhosin?) script would always block and give a 500 error when the files in adminzone are set to 777 permissions!

WHAT?!

OK, the permissions were reset at their end, and I have to say that I DID NOT do anything deliberately to make that sort of stupid error.

The site has started to come back -  slowly!

Problem-2

Now I find that nothing with 'site' in the URL will show, giving the dreaded 'Internal Server Error' (without the 500). Examples —
  • http://← domain name –>/site/pg/start - gives the error
  • http://← domain name –>/pg/start - does not

1. Checked redirects, but since I hadn't touched that area, that doesn't throw any light on the matter.
2. Did a file integrity check, but that only threw up spurious 'added' files that I already knew about.

My host reckoned it was the incorrect permissions, but also threw some doubt on the number of processes spawned, which they have set not to exceed 25. However, in his haste to get my site back up he forgot to check what the ACTUAL number of processes was.

Where should I start looking to get back on track?

 :'(

Take my advice. I'm not using it!

View my working ocPortal site (version 9.x.x) at Anglo-Indian Portal
Back to the top
 
Posted
Rating:
#63527
Avatar

Community saint

I am *bumping* this as I've just spent the best part of 40 minutes talking to a recalcitrant web host and not getting anywhere fast!

I decided to check that they hadn't inadvertently blocked 'site' access. Of course they had, or rather their stupid suPHP script was blocking my site from running, because of the 777 permissions in my '_custom' folders'

The host (who even have an installer for ocPortal on their cPanel) say that they cannot allow ANY folders to run with 777 permissions. That's it. No further discussion!

My question is, if they, and other hosts, start to take this line, what is the future for ocPortal?

Short term it looks like I will have to demand a refund of my money (fat chance of getting that back!) and then hunting around for a host (probably Elief) who is prepared to agree to accepting my setup BEFORE signing a contract.

Hell of a state of affairs!

Take my advice. I'm not using it!

View my working ocPortal site (version 9.x.x) at Anglo-Indian Portal
Back to the top
 
Posted
Rating:
#63535
Avatar

Community saint

*bump*Update:*bump*

1. Ran upgrader
2. Checked permissions - apparently OK
3. Took hosts to task, but didn't win the war
4. Re-checked permissions, but this time manually on the server
5. Several root folders, which included 'site', 'lang' & 'pages' were set to 777
6. Changed these to 755
7. Left any '_custom' folder below the root at 777
7. Site working again

Now I need to double-check permissions against the ocP permissions advice for a manual install to see that nothing is crippled from the user end.

Looks like the hosts had a reason to complain when they were seeing root folders set to 777.

Can staff clarify what a user should expect the install to show (I think I know where to look, but it would be reassuring to have it spelled out), and whether 'incorrect' settings (ie root settings set to world-writable) are also checked when the upgrader is run.

BTW, all the problems started after running the clean-up tools in version 5.0.2. I cannot be more specific than that, other than to make the point that root folder permissions, including 'adminzone', got changed to 777 after running one of the sections. Can't tell you which one, and not about to repeat the experience to try to identify which!

 :dry:


Update:
Checked the permissions and found that just about every 'necessary' permission, as indicated in the manual installer advisory, needed to be reset.

Yet the 'Permissions check' feature in the upgrader gave the whole site a clean bill of health!

 :'(

Take my advice. I'm not using it!

View my working ocPortal site (version 9.x.x) at Anglo-Indian Portal
Back to the top
 
Posted
Rating:
#63562
Avatar

Right, sorry to hear of your problems. It's an unfortunate situation in the world of web hosting that each server has different requirements.
So you're on a server that:
a) won't allow excess permissions:
b) I think you may be on a server with SuExec which means that the web server runs as your main user account, not a specific account belonging to the webserver. So you may not need any permissions at all. Then again you said they "needed to be reset" so maybe I'm wrong in my analysis there. Were you getting errors about a lack of write permission when they weren't set?

In terms of what folders need write permission (on a non-suexec server) – it's anywhere where the server may need to create new files. That's mostly the upload directories, the Comcode page directories, etc. Directories intended for PHP files like 'sources_custom' don't need it – if anything goes in there it'll be you putting it there manually. So there's no fundamental problem, but I am 100% with you that this is all really confusing.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#63566
Avatar

Community saint

Chris,

It has been a couple of days since the 'fiasco' with my hosts, but on closer reflection there were some actions taken that might have led to misunderstandings about host/software/permissions - not necessarily in that order.

Allow me to expand on that:
  • the hosts say they are running suPHP which will not allow ANY 777 permissions
  • that isn't exactly a true statement as I have found that:
    • 777 permissions set on any root directory of the installation of ocPortal are blocked from running and I end up with the 'Internal Server Error'
    • 777 permissions set on directories BELOW a root directory are allowed to run
  • When I first contacted my hosts (twice) to check my site for the 'Internal Server Error' and take any action necessary, each time the dumb@sses immediately reset ALL the root folders to 755, which effectively reset the folders below them.
  • So I think there was a combination of events here. Somehow, in running the cleanup tools, there was an incident that 'changed' all permissions for ALL directories to 777 (which may explain why my host found my adminzone directory set to 777).
  • The second action that compounded the problem was the techs arbitrarily resetting the global permissions to 755 for all directories. I was less than complimentary on the second techs actions, and explained that there was a requirement for some of the directories to retain 777 permission and that "… he shouldn't be changing things on my site installation when he didn't know anything about the software that was driving it!" I received a "Sorry, won't happen again." response, but obviously the damage had been done!
  • Which resulted in me having to manually rest the permissions.

After a few 'experiments' at changing directory permissions, this is what I've ended up with. Something about which I have no idea as to how elements and usability are going to be affected in the future; although the site appears to be running OK until now:
  • lang_cached - 755
  • lang_custom - 755
  • persistant_cache - 766
  • safe_mode_temp - 766
  • sources_custom - 755
  • text_custom - 755
  • tmp - 766

All other 777's as required by the manual installation advisory are in place, i.e. all '_custom' folders and others that require 777 are in place and are not being blocked.

Sorry for the 'long' explanation, but I thought it best to clear up any anomalies that might result in you guys chasing your tails looking for 'screw-ups' that aren't necessarily there!

 :(

Take my advice. I'm not using it!

View my working ocPortal site (version 9.x.x) at Anglo-Indian Portal
Back to the top
 
Posted
Rating:
#63624
Avatar

Thanks. I don't think ocPortal cleanup tools would have changed permissions though. The only part of ocPortal that does mass permission changes is the fix permissions feature in the upgrader.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#63630
Avatar

Community saint

Chris Graham said

The only part of ocPortal that does mass permission changes is the fix permissions feature in the upgrader.

I clicked that too in my desperation to get the site back on line. Perhaps it is the culprit. Are you able to check its functionality in a testbed?

Take my advice. I'm not using it!

View my working ocPortal site (version 9.x.x) at Anglo-Indian Portal
Back to the top
 
Posted
Rating:
#63633
Avatar

The thing is, even that only chmods stuff that is white-listed for it in our code. It's the same list of files/directories that ocPortal checks in the installer. It checks to see if each of those files/directories is writable and if not it changes the permission.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#63635
Avatar

Community saint

OK. I shall treat things with a bit of caution when using the appropriate tools.

My question in #63566 above, will changing these permissions to 'non-standard' affect my installation adversely?
  • lang_cached - 755
  • lang_custom - 755
  • persistant_cache - 766
  • safe_mode_temp - 766
  • sources_custom - 755
  • text_custom - 755
  • tmp - 766

Looking for reassurance from the expert!
 :thumbs:


Take my advice. I'm not using it!

View my working ocPortal site (version 9.x.x) at Anglo-Indian Portal
Back to the top
 
Posted
Rating:
#63637
Avatar

lang_cached, lang_custom, sources_custom, and text_custom – ocPortal does not write to these, so it shouldn't need anything special.

persistant_cache – this would need to be 777 if you had file-based persistant caching on, and you don't and shouldn't (it's a developer thing really).

safe_mode_temp – this would need to be 777 if the PHP installation is set to 'safe mode'.

tmp – this is a left over from installation anyway, you shouldn't need it.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#63645
Avatar

Community saint

Suggestion:

Can future CHMOD information and checks reflect a change to 755 permissions for these root folders by default?

A special note to developers and 'safe mode' installers during installation would forewarn these groups about what needs to be changed to 'world-writeable' to achieve their aims.

This should alleviate headaches for your 'average-to-dumb@ss' users and satisfy overly cautious web hosts.

Take my advice. I'm not using it!

View my working ocPortal site (version 9.x.x) at Anglo-Indian Portal
Back to the top
 
Posted
Rating:
#63650
Avatar

I'm a bit confused by what you mean. If excess permissions are set on the root folder, the installer is itself going to not be able to run. If not enough permissions are there – well, ocPortal does not need write permissions to the root folder.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#63659
Avatar

Community saint

I hadn't considered the fact that had my hosts set up their 'suPHP' before I installed, I wouldn't have been able to install at all. Must take that up with them, considering they have an ocPortal installer in their cPanel.

My point was, if the 777 permissions on the root folders are now considered 'unnecessary' for the majority of the folders I've identified in my previous posts, can they not be set to 755 by default right from the 'get-go'?

That way, nobody is going to fall foul of a host with over-strict security permissions - ever.

Yes? No?

Take my advice. I'm not using it!

View my working ocPortal site (version 9.x.x) at Anglo-Indian Portal
Back to the top
 
Posted
Rating:
#63664
Avatar

I am still a bit confused, because we don't advise to set those permissions. Do you mean our quick installer sets them like that?


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#63666
Avatar

Community saint

Now that's two of us. Confused, that is!

ocPortal Tutorial: Basic Installation is where I get my information.

Take my advice. I'm not using it!

View my working ocPortal site (version 9.x.x) at Anglo-Indian Portal
Back to the top
 
Posted
Rating:
#63671
Avatar

Ah, I understand now. Those folders you listed were listed by us, and that was a mistake. sources_custom in particular should not be listed.
I'll rectify that.

EDIT:

I'm actually going to leave these ones listed: lang_cached, lang_custom, and text_custom
It's not strictly needed, but if languages are added in an adhoc way ocPortal can fix itself if there are permissions on these.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#63675
Avatar

Community saint

Chris Graham said

I'm actually going to leave these ones listed: lang_cached, lang_custom, and text_custom
It's not strictly needed, but if languages are added in an adhoc way ocPortal can fix itself if there are permissions on these.

OK, Chris. But I can see trouble ahead if they are listed as 777.

I will continue with my folders amended to what I showed before, and if problems arise I can ask for more guidance from you.

Thanks for looking at the problem so thoroughly.

Take my advice. I'm not using it!

View my working ocPortal site (version 9.x.x) at Anglo-Indian Portal
Back to the top
 
There are too many online users to list.
Control functions:

Quick reply   Contract

Your name:
Your message: