Goodmorning gentlemen! A new day has arrived once again
How nice to see this resulted in a philosophical debate but let me respond to the matter at hand.
dspaan wrote:Thanks! i added the --HTTPS flag to crontab
I enabled this but now of course the links to the recordings still have the server IP in the URL which will cause your browser to give an invalid certificate message, unless you install a Let's Encrypt certificate for the server ip i guess, didn't try.
blackbird2306 wrote:Admin --> Servers --> Select Server --> Select in "Recording Web Link" option "ALT_IP" and fill the "Alternate Recording Server IP" field with your FQDN.
This won't change the url in your database in real, but it will pretend the FQDN by replacing the database url.
I have enabled this and this was an easy solution! Working nicely.
williamconley wrote:Do not change your server IP just to edit the domain of the recordings link. Unnecessary (and risky if done improperly).
* The server upon which Vicicial resides may have as many domains as you choose to point to that server's IP address. No limits. Vicidial neither knows nor cares.
* The domain in the URL will act exactly like the IP, you may substitute one for the other at will (unless you alter the apache configuration to block this: But if you do, you'll know you can point any domain anywhere you like without altering Vicidial's configuration).
* If you want the links Inside vicidial to change: Have a look at the options for this server under admin->Servers. Alternate IP, External IP ... these can be used to modify the URL presented to those who click on the recording links without altering any Vicidial configuration files or options. Once you've decided on "alternate" vs "external" (no difference really, but read the ?) then set "Recording Web Link" to your choice and the recording links are altered WITHOUT editing anything else in the system.
This is true but in this case, this is a small virtualized vicidial server with less then 10 agents on it and a single FQDN.
williamconley wrote:blackbird2306 wrote:williamconley wrote:start a ftp transfer only to change url in database
Actually, no: The Vicidial system stores ALL recordings in a single folder. This is a very bad thing.
* Over time that folder will fill up and it can literally become impossible to even view the list of files in the folder and very difficult to manage the files as a result.
* Storing the Audio Recordings on the same HD as the Vicidial Database allows those recordings to fill the HD and crash the system. Any time drive usage exceeds 75% we warn clients. Over 90% and production is notably affected. Over 95% and crashes begin to occur regularly. At 100%: System goes offline ... and now the client will begin to wonder if they should put the recordings somewhere else. We get these calls a lot.
* If the HD dies those recordings are all GONE. If you back it up and the HD dies, then you have thousands (hundreds of thousands?) of recordings to restore that have no reason to be on that HD any more. Takes much longer than restoring without those files. And Vicidial's backup script doesn't back them up in the first place, so you need a different method to back them up.
* Access to those files requires access to the Vicidial server itself. Even If you provide a direct link to just that one file, you must allow web access to the Vicidial web for it to work. If you move the files to an FTP server, however, access to that server is not related to Vicidial.
However: If you activate the FTP service and push those recordings to another server, those problems are solved.
Even if you use FTP on the SAME server you can solve all those problems pretty easily. Second HD mounted in the /home/ folder for instance will remove the need to restore that drive if the Vicidial HD dies. If you require redundancy, mirror that drive. The FTP system segregates the recordings into daily folders, so no single folder will ever be so full that it's difficult to manage.
So it's not just about one thing. FTP pushing is not difficult, but it has been known to save a lot of headaches over time (just like NOT using it has Caused a lot of headaches over time ... and resulted in support calls to us that we make money from, but we prefer Coding and Hosting for money more than fixing broken systems).
Yes i have experienced many of the issues you mentioned in the past, servers getting stuck and not being able to browse the recording directory. What we now do is use this part of the crontab to remove them after 90 days:
- Code: Select all
### remove old recordings more than 90 days old, and delete originals after 1 day
24 0 * * * /usr/bin/find /var/spool/asterisk/monitorDONE -maxdepth 2 -type f -mtime +90 -print | xargs rm -f
24 1 * * * /usr/bin/find /var/spool/asterisk/monitorDONE/ORIG -maxdepth 2 -type f -mtime +1 -print | xargs rm -f
But of course this still does not factor in how many agents and thus recordings will fill up the disk and the issue can still happen. So i will look into setting up some kind of extra storage for recordings. Ideally a central server for different clients.
Furthermore i noticed in this script the following:
/usr/share/astguiclient/AST_CRON_audio_2_compress.pl
- Code: Select all
# 80302-1958 - First Build
# 80731-2253 - Changed size comparisons for more efficiency
# 90727-1417 - Added GSW format option
# 101207-1024 - Change to GSW option because of SoX flag changes in 14.3.0
# 110524-1059 - Added run-check concurrency check option
# 160523-0652 - Added --HTTPS option to use https instead of http in local location
# 170212-0732 - Added --file-sorting option to put files into dated directories (THIS WILL NOT ALLOW FTP ARCHIVING)
So it is possible to place recordings in different directories without the FTP option.
blackbird2306 wrote:That's why I asked him:
The question is why do you want to change the working ip in your recording links?
The reason i started this thread is that the client who is using this server asked this question, the most important part was using https and not http but because of not having a cert for the IP the other part (using the FQDN in the URL) was still relevant.