search

AllStarLink / app_rpt

Refactoring and upgrade of AllStarLink's app_rpt, etc.
3 stars 2 forks source link

archivedir creation and settings #341

Closed tsawyer closed 1 day ago

tsawyer commented 4 days ago

Email from a friend setting up an apt install asl3 on amd64 and his experience and findings with adding archivedir = /var/spool/asterisk/monitor

So, apparently I wasn't looking deeply enough into the spool directory at the 
bottom of this thread.  I should have looked into the directory UNDER the monitor 
directory (the directory named after the node name being monitored)... that is, 
assuming I hadn't messed with the permissions of the monitor directory back on 
6/22 (which I may have)...  the only way to know for sure would be to install a fresh 
copy of ASL3 now but I don't have a platform to do that at the moment... *so*, here 
is what I did tonight:

root@allstar:/var/spool/asterisk/monitor# ls -alst
4 drw------- 2 asterisk asterisk 4096 Jul  2 00:01 43763

root@allstar:/var/spool/asterisk/monitor# chmod 700 43763

root@allstar:/var/spool/asterisk/monitor# ls -alst
4 drwx------ 2 asterisk asterisk 4096 Jul  2 00:05 43763

and the recording started working and the permissions errors stopped... so setting the 
"eXecute" bit is what fixed it, as your surmised.  NOTE: This bit was NOT set in the old 
version and it worked just fine; so something has changed...

So... there seems to be a bug that someone will need to hunt down... creating the directory 
with the "eXecute" bit set may not be the proper solution (maybe there is a deeper issue, 
as you suggested); but it is a "hack" that works for me for now.

Also, it would be nice if someone would clean up the error spit out by rpt_master 
to include the details of the file it can not write similar to what ast_writefile is 
showing below, in order to help with debugging.

Ken
Allan-N commented 4 days ago

Yes, directories should be created with the execute bit.

netsound commented 3 days ago

Before since we were running under root it was doing it without issue. Now under the asterisk user/group it is an issue as the current code is writing out with 0600 for permissions. Could this get set to 0760 at least.

Allan-N commented 3 days ago

Could this get set to 0760 at least.

0760 (-rwxrw----) doesn't make any sense. If you are looking to open up "read" access to others then 0750 (-rwxr-x---) or 0755 (-rwxr-xr-x). But, at the moment, even opening up access to the directory won't help because the files are created 0600 (-rw-------)

netsound commented 3 days ago

I meant on the file's written.. 660 vs 600 as it's doing now.

Allan-N commented 3 days ago

I'm hesitant to have the default filesystem permissions be too open. Changing the directory permissions to 0700 should take care of the permission errors.

But, at the same time I do see how changing the permissions on the "files" could be helpful. Then, if you opted to open up the directory permissions then the files would become accessible.

In short, I'm thinking 0700 on archivedir, 0755 on the archivedir sub-directories, and 0644 for the files. Reasonable?

netsound commented 3 days ago

I would think so... That way a script to "process" the files doesn't need to be run as root but could be any member of the group was my thinking.

Allan-N commented 3 days ago

I just made one last [?] change.

I changed the archivedir sub-directory modes to 0775 (instead of 0755). This way, if you ensure that whatever job you are using to "process" the files is a member of the "asterisk" group you will then be able to remove any processed files.