Wednesday 11 August 2004 12:29:40 am

Patricio,

Greetings. I think I understand most of your original message.
I am just uncertain about how you "cloned" the site, so I would
ask that you give a little more detail on how you did the "cloning"
so I have the proper background to give a quality answer.

What command(s) did you use to "clone" the site?
What Operating System are you doing the "cloning" on Windows or Linux?

Have you checked that the settings/ , var/ , design/ directories have the correct permissions? Confirm Permissions of Settings, Design Overrides & Var:

# cd html ;
# chmod -R 777 var/ settings/ design/
# ./bin/modfix.sh
# ./bin/shell/clearcache.sh --clear-all

About 3/4 into the creation of this response I released that the answer may be simpler. Assuming for the moment that you did just copy the eZ publish installation directory then . . . you may have forgotten to re-run the setup of eZ publish to configure the "cloned" copy to use a different database than your original installation database. Which makes sense because you say that deletions on the cloned site also remove information from the original site.

I would also suggestion you check the database information in your settings/ files. Example:

settings/siteaccess/news/site.ini.append.php 

[DatabaseSettings]
DatabaseImplementation=ezmysql
Server=localhost
User=publish3
Password=publish3
Database=ezpub_publish3
Charset=
Socket=disabled

[SiteSettings]
SiteName=eZ Pub
SiteURL=ezpub.co.uk
LoginPage=embedded
IndexPage=/content/view/sitemap/2/

Settings References:
http://ez.no/ez_publish/documentation/configuration/configuration/configuration_files
http://ez.no/ez_publish/documentation/ez_publish_basics/the_internal_structure_of_ez_publish/directory_structure
http://ez.no/ez_publish/documentation/incoming/design/designs_and_siteaccesses
http://ez.no/ez_publish/documentation/installation/the_setup_wizard
http://ez.no/ez_publish/documentation/incoming/design/siteaccess_configuration
http://ez.no/ez_publish/documentation/ez_publish_basics/site_management_in_ez_publish/site
http://ez.no/ez_publish/documentation/ez_publish_3_4/using_settings_object_to_change_ini_settings

Permission References:
http://ezpub.co.uk/faqs/development/ez_publish_3_4_0_to_3_4_1_upgrade
http://ezpub.co.uk/faqs/installation/i_can_t_login_after_installation

Hey Patricio, I would still encourage you to reply answerers to my questions if any of the information in this post does not lead to a solution for you. With more information from you about your installation I'd gladly keep trying to help you find a solution.

Cheers,
kracker
Just Your Out of the Ordinary Pathetically Unique Pale Face Punk Programer

Them (Dose-One, Jel) - Another Part of the Clown's Brain

Metallica - Four Leaf Clover

Member since: 2001.07.13 || http://ezpedia.se7enx.com/

Wednesday 11 August 2004 3:53:08 pm

Tony,

Please but in by all means, I don't want to be giving out bad solutions / answers.
If I make a mistake . . . I want to know, I have to know.

You bring up a very valid point that has bothered me for a long time.
I just have a few questions now based on what you say about using more secure permissions than 777.

1) Shared Host Permissions

Some users don't have root access to their server (shared hosts) and it is difficult for them to work on an eZ publish site and avoid user and groups permission problems.

I have had the experience that my files were set to the user & group of the host. Which allowed me to edit the files (initialy) usernameuser : usernamegroup

Later any files created or modified by eZ publish (settings/ini files, uploaded files, cache files) would be owned by the web server user ( apache : apache )

I would have to request the shared host admin to run a command to give me user & group ownership of the files to be able to change them (frustrating for both parties). Only to have it come up again and again because my user was not apart of the apache group.

Also it seem only root can change ownership and group settings of files.

2) VDS Host Permissions
Most VDS users have root access and can fix any permission problems. They also have greater freedom to secure their eZ publish user and groups permissions. Still there are problem which do arise from having the apache server running as the user apache while editing and creating files as another regular user.

These are just a few things I have experienced.
Which have lead to my (incorrect) thinking that permissions of 777 would solve most of my permission problems most of the time. I guess I'm lucky that I have not experienced security problems with insecure eZ publish permissions . . . yet. I guess depending on your background Linux / Unix Administration & Security or eZ publish developer / user your solutions to different problems may differ and the mileage for each solution differ as well.

Quote (Clipped):

Just a quickie on permissions. 
Might I suggest that setting 777 on files is a bad idea. 
This will make all your files world writable and world readable. 
If possible could you chown -R apache and then chmod -R 700. 
You can or course create groups etc. 
One of the major exploits in the unix world is 
when files are set world read and writable.

\\kracker
Dan Bern - Jerusalem

Member since: 2001.07.13 || http://ezpedia.se7enx.com/