Clonning Site Issue.

Author Message

Patricio Villacorta

Tuesday 10 August 2004 1:57:17 pm

I am using ezpublish 3.3-3. all work fine for a couple of sites running. Now i clone one of these sites (design folder, storage folder, db folder in mysql holder, and clone the siteaccess references).

Next step, i change settings in cloned siteaccess folders, i.e. bd name, storage folder, design to use, name of site.

New site cloned work fine... the problem appears when beginning to delete articles, objects under admin interface of my new site (cloned site)... all this task work fine... but when i check my old site, i note pictures missings... these pictures not exists anymore in storage.

Is possible when i erase all this stuff in my new site (cloned site), ez delete references in both storages? (original and cloned storage).

Im not look it into the ez code for discover how operate delete tasks.

Thanks in advance.

Bård Farstad

Wednesday 11 August 2004 12:20:05 am

The reason for this is because the full path of the images are stored in the database. This means that eZ publish does not know that you've moved/copyed the images to a new path and then just deletes the image from the old path.

The path is relative to the eZ publish root, so if you would copy the whole installation it would work. Then mabye after removing the articles/images from your cloned site you could copy the data back to the original installation ( if you would like to run both sites on the same installation, which is more effective ).

This problem is actually beeing worked on and is one of the things which will be improved with the image system in 3.5.

--bård

Documentation: http://ez.no/doc

kracker (the)

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/

Tony Wood

Wednesday 11 August 2004 12:48:33 am

Hi kracker, Patricio

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.

Sorry to butt in on the thread but one of the major exploits in the unix world is when files are set world read and writable.

Also might I suggest you use ./bin/shell/clearcache.sh --clear-all instead of ./bin/shell/clearcache.sh as the --clear-all ensures all the caches are cleared not just the content cache.

Sorry to butt in

--tony

Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development

Power to the Editor!

Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future

kracker (the)

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/

Tony Wood

Thursday 12 August 2004 2:35:29 am

Firstly, Apologise to Patricio for highjacking the thread.

Hi Kracker,

Don't worry about not knowing stuff, we *all* don't know things, finding stuff out is the joy of working with collaboration systems like eZ.

>>Shared Host Permissions
your right shared system do have some problems with permissions. But the key is to find a hosting provider who allows you to set permssions yourself. You do not need root access for this just a well setup environment. In fact giving people root access is a problem (read Win98, Inspire and default MS Windows environments.) Most people strive never to use root as it is a hammer to crack a nut. "With great power comes great responisibility"

>>VDS
You're right chmod -R 777 will solve your permission problems and will get your system working. It has been a long help issue for me that the modfix.sh script contains 777. But I can understand it because the goal of the eZ download is for development not for standard role-out. There are no right answers for permissions as they vary from OS to OS, hosting provider to hosting provider and directory to directory.

The real knack here is not to push one or other hosting environment (as I have a personal interest here) but to make eZ publish work on as many environments as possbile to ensure that developers has a choice and can pick the provider who suites their needs. eZ are working towards that and it has meant that there are now more eZ publish sites that ever which is a great thing.

It is up to each hosting provider to provide the right information to their customers to advise them as about security for their environment. The problem is creating a secure site can take a little longer. But it is vital.
Of course you could host your own environment but then you really need to be experienced in system administration.

-- tony
http://www.visionwt.com

Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development

Power to the Editor!

Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.