file and directory permission for developers

Next topic

Author	Message
Francesco Ronzon	Tuesday 04 May 2010 6:05:51 am Hi, I'm the System Administrator of some servers (linux/debian) with several EZ installations. Our developers need to work on a couple of EZ installations already in production, but, as suggested by EZ documentations, most of EZ directories and files are owned by the apache user and its group (www-data), so they cannot have permission to do it. The question is: which EZ directories really need to be readable/writable/executable by www-data? I'm sure we are not the only ones to face this issue, so I thank you in advance if you can suggest some links to previous answers (yes,I've tried the search function in this forum, but did not get anything) /francesco
Christian Rößler	Tuesday 04 May 2010 7:20:18 am Hy, the most minimal solution is to give www-data write permissions (recursive) to the var directory of eZPublish. In there are stored the cache files, uploaded media-ressources (pdfs, images) and other stuff i cant remember right now. A plus would be to give www-data writeaccess to settings/siteaccess/* and settings/override directorys when users would like to edit eZPublish ini-configurations via the admin-interface. I've never enabled/done that, so cannot totally ensure if above directorys are sufficient. Another thing you might consider is give www-data permissions to design/* and/or extension/XXXX/design/xxxx/override/... folders if your developers tend using the ezpublish frontend-functionality to create template-overrides. I've never done this so I cannot ensure if those folders are the corresponding ones. I've setup the files to be group writeable for www-data chmod g+w xxx and chgrp www-data xxx so your developers are still the owners and www-data is able to write too - mostyl ;-) cheers, chris -- edit: added recursive statement and explanation of var directory Hannover, Germany eZ-Certified http://auth.ez.no/certification/verify/395613
Francesco Ronzon	Wednesday 05 May 2010 11:03:33 am Thanks Chris for the answer. The problem is that there are more than one developer on each installation, and I don't want them to share the same account, so they normally own a file/dir, and give full permission to the 'users' group so others can work on it, too. Then, as you said, you are not sure about your advice but I cannot make any mistakes (since all installation are in production already)... So, does anybody have an answer? (to be honest it seems a bit weird, to me, it's just us facing this issue: sure there should be some documentation already published, isn't it?) ciao, Francesco
Bertrand Dunogier	Wednesday 05 May 2010 11:46:21 am I can't think of any major lack in Christian's list. The first one (var) is mandatory. Settings and design depend if you use the extensions & design features from the GUI. Bertrand Dunogier eZ Systems Engineering, Lyon http://twitter.com/bdunogier http://gplus.to/BertrandDunogier
Gaetano Giunta	Thursday 06 May 2010 1:07:18 am @francesco "more than one developer on each installation" - I think you'd be better off using an scm tool where you can control complete change history on every file, rather than try to segregate developers using file permissions - at least as far as the dev and integration servers are concerned. If you are talking about a prod server, giving each dev/admin an account, and making them all members of the same group is ok. I confirm the list that Christian gave: - by default only var/ needs to be writable - var/autoload needs to be writable by apache if you want to be able to activate/deactivatate extensions via the admin gui - settings/override, settings/siteaccess and extension/xxx/settings needs to be writable by apache if you want to be able to edit settings via the admin gui - design/ and extension/xxx/design needs to be writable by apache if you want to be able to edit templates via gui some more advice: - you do not need to have stuff in var world-readable, if www-data is the group to which belong both the devs and apache. You can look for file permissions uses by ezp when creating things in config.php (EZP_INI_FILE_PERMISSION) , file;ini and image.ini - if you run your cronjobs by processes other than apache, take care that if they crash they might leave lock files in the var/siteaccess/cache/ezmutex that later cannot be removed by apache. You can set up a cronjob to fix this - setting up a cronjob that periodically checks for file perms is also a good idea if you fear your devs will create problems when uploading stuff with the bad provileges Principal Consultant International Business Member of the Community Project Board