views:

149

answers:

3

In our project we writes lots of application logs(sometimes they are very useful) in tmp folder.

In this folder we have components' directories, such as:

  • api
  • email2sms
  • scheduled_sending
  • billing
  • etc. Less than 10 folders, in summary.

The problem: new component's folder arise with time - each of this folders has to be writeable.

So it takes time for every developer to chmod each of this folders in their local environments, it takes time to chmod those folder in production.

How this problem can be solved? How this process can be automated(Apache Ant task, SVN properties, application's script - which has to be responsible for the task)?

Environment: Development environments - Ubuntu, Windows; production - FreeBSD

+1  A: 

the one (program/component) who creates the log should be responsible to make the log files writable to everyone - to use mod=777 (everyone writable) when the logs are created.

if you deploy process has an installation script, also do that in script.

Francis
What should I choose - installation script or Apache Ant task - which will set all the permissions(isn't in an antipattern?). If it has to be a script - when and how it has to be called - run script in Apache Ant's "build" task or somethig? Please help
Fedyashev Nikita
A: 

mkdir and chmod in a simple shell script should be sufficient.

John Cromartie
+3  A: 

The quick-and-dirty method that I've used in most of the companies I work for was something like this:

  1. Put all the code in a versioning system (like SVN or something) so that all the developers have a single source of the files. You're obviously already doing this. Hurray!
  2. Put in the root of that code, a file named setup_permissions.sh which updates all the local environment stuff. This can include permissions, or whatever you need to run.
  3. Every morning, all the programmers do svn update, which updates the files, and also the setup_permissions.sh.
  4. They try to run their code. See a problem. They run setup_permissions.sh.
  5. All is well in the world!

As for the contents of setup_permissions.sh, it could be something like:

#/bin/sh
TMP=/tmp

mkdir $TMP/api
mkdir $TMP/email2sms
mkdir $TMP/scheduled_sending
mkdir $TMP/billing
chmod 777 -r $TMP/api $TMP/email2sms $TMP/scheduled_sending $TMP/billing

And add any more commands you feel you need.
(Oh, and don't use chmod 777... it's a terrible idea. Just see this as an example.)

The key to this approach is discipline. You must trust your programmers to have the discipline to run the setup_permissions.sh when they update their local environments . The same goes for whoever updates the production system.

You must also have the discipline to update setup_permissions with any changes you make to the directory structure, and whatever permission change it needs - instead of just doing the changes manually on your computer, and leaving it at that. (And the same goes for all the other developers who make changes to the directory structure.)

scraimer