asterisk dapper.2114_to_dapper.2234 diff

[Diego Iastrubni]

Hi,

See commend inline:

On Monday 07 August 2006 12:16, Jonas Smedegaard wrote:
> > -#chmod -R 0664 /etc/asterisk/
> > +#chmod -R 0660 /etc/asterisk/
> This one should certainly be enabled, I suspect!
Does anyone needs to read this dir outside of the "asterisk" familiy? -> 660 
IMHO 664 is enough, but who knows... 

I am commenting out the line with 660, lets see what breaks (don't forget also 
the subdirs like manager.d, extensions.d, etc):

chmod -R 0660 /etc/asterisk/
find /etc/asterisk/ -type d | xargs chmod ug+rwx

> >  #find /etc/asterisk/ -type d | xargs chmod a+rx
> > -#chmod +t /etc/asterisk/
> > +#chmod g+s /etc/asterisk/
> This looks odd to me. Both old and new command. Please elaborate.
Yes.. I know... Tzafrir and me do not agree on how to solve this problem, but 
this is the main idea:

The creating of files inside this directory may come from the asterisk user, 
or www-data user. Sometimes by admin scripts running by "asterisk" user, and 
sometime by some web interface (which run as the user www-data, which is part 
of the asterisk group).

The sticky bit is my fix, Tzafrir fix is to patch the scripts to "chmod" the 
created files.

> Why indent?
...
> > \ No newline at end of file
oops... my bad on both...

> > +  * Vaiours fixes to asterisk_fix
> Vaiours -> Various
check.

 > $(CURDIR)/debian/tmp/usr/share/asterisk/firmware/iax
>
> Did you remember to invoke the script from asterisk postinst?
>
> And why provide as a separate script, if only relevant in the asterisk
> postinst?
No need to do this on the asterisk package, but on the asterisk-config 
package. The problem is that I want the same code to be run as part of the 
asterisk-config-freepbx package (which is on the svn, under the source code 
"freepbx", but still not been build). This package will be installed instead 
of asterisk-config:

apt-get install asterisk-config-freepbx asterisk

> I mean, if the purpose of the script is not only to correct mess done
> by earlier packaging, but general fixup of whatever the local user may
> mess about, then it is certainly too limited now ;-)
not only earlier, but future packaging.