Quinntin Comer
-
Posts
14 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Quinntin Comer
-
-
9 minutes ago, Vodia PBX said:
You can use this link for now: http://portal.vodia.com/downloads/pbx/version-69.1.xml we'll update the links soon.
Excellent! Just updated our instance
-
Appreciated! Cant wait to update the instance.
Is there a URL available for the update? I do not see it in the release notes and it is not available in the updates feed in the PBX. I see you the Windows release is lagging behind, but what about Linux?
-
4 hours ago, RichardDCG said:
I had to modify this line to ... (remove "'s and add - to exec)
find $backup_dir/*.tgz -mtime +7 -exec rm {} \;
Other than that everything else works perfectly, very helpful, thanks!
Glad that was useful for you!
-
@Vodia PBX I only asked if one existed. How do the partners get their hands on that or in what format is that available? I would love to see what's coming down the pipeline.
-
On 9/12/2023 at 5:17 PM, Scott1234 said:
Noice. thanks for sharing!
I use this to replicate every hour to another datacentre for a worst-case scenario. It only does the changes with a bandwidth limit.
@hourly rsync --bwlimit=2048 --delete-before -av /usr/local/pbx ******@****.***:/usr/local/
Absolutely could add that as a step!
-
On 9/12/2023 at 1:12 AM, Vodia Support EU said:
We don't really have anything official. We currently see our most important task in the stability of the PBX. A system can never be too stable.
As soon as we start writing/talking about innovations, experience teaches us that there will be customers who insist on exactly these innovations and will force us on. Experience shows that this in turn will be at the "cost " of the stability of the PBX.
Of course there will also be new functions, I think I can say that we are not lagging behind with our range of functions at the moment. We will also announce some of the new developments in advance. But as I said, we see the current focus in the stability of the PBX.
This seems like an interesting response. I am not sure why the immediate jump to defensiveness. Nowhere in my post did I attack the development cycle, say that Vodia, was lacking, etc. When you are a "partner", you want to feel like a partner. You want to be partners in eachothers success.
I dont think I have ever partnered with a product that doesnt have any established roadmap to let its partners know where its going...
Certainly this cannot be the case? There is at a minimum some kind of yearly roadmap or goals? -
Hi folks,
Thought I would share this in case anyone was interested. This is just a daily script for backing up the PBX data directory.
We have a file "vodiapbx-backup" in the /etc/cron.daily folder with no extension, just named "vodiapbx-backup", so that it will run dailly.
You can see when your cron jobs are scheduled by running the following command:
grep run-parts /etc/crontab and you will see results similar to: 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
Based on the results above, you can see our daily will run at 6:25 daily.
https://crontab.guru/#25_6_*_*_*
In that "vodiapbx-backup" file, we have the following script:
#!/bin/sh # Set the variables source_dir="/usr/local/pbx" backup_dir="/data/backups" now=$(date +%Y%m%d) filename="VodiaPBX_Backup_$now.tgz" # Delete backups older than 7 days echo "Deleting older backups" find "$backup_dir/*.tgz" -mtime +7 exec rm {} \; # Start Backups echo "Starting Backup" tar -zvcf "$backup_dir/$filename" "$source_dir"
This script will perform the following:
-
Define the following variables:
- source_dir: This is the source directory we want to backup
- backup_dir: This is the path where we want to store our backup (in our case, we have a mounted volume)
- now: This is the current datetime stamp with YYYY/MM/DD format.
- filename: This is the filename to use for the backup file, example: VodiaPBX_Backup_20230912.tgz"
- Deletes any tgz files older than 7 days from the backup_dir path
- compresses the source_dir path into $backup_dir/$filename
-
Define the following variables:
-
On 9/8/2023 at 1:05 PM, Vodia PBX said:
The thing is that it seems to work in our environments without the data... Anything in the inspector regarding code that does not come from the PBX?
Nope. This is from multiple browsers, machines, incognito, etc. maybe something specific to the AWS template, but that part I cannot really say.
-
Is there a roadmap available? Coming features? Plans? etc?
-
Just now, Vodia PBX said:
Yes an obvious fix would be to add blob: to it (or data?). However it should not use data. I am wondering what is triggering it to use data... It should not do that unless there are some obscure libraries at work...
Definitely a mystery for the Vodia PBX team. I have tried it from multiple computers, multiple browsers, etc.
I dont know if its something specific to the image in the AWS marketplace or not. -
I was able to resolve this with the following modifications:
usr_portal.html
[[#header name="Content-Security-Policy" content="default-src 'self' data: 'unsafe-inline' https://fonts.gstatic.com https://cdnjs.cloudflare.com https://accounts.google.com; style-src 'unsafe-inline' 'self' https://cdnjs.cloudflare.com https://fonts.googleapis.com;"]]welcome.htm:
[[#header name="Content-Security-Policy" content="default-src 'self' data: https://accounts.google.com 'unsafe-inline'; child-src 'none'; frame-src https://accounts.google.com"]] -
No, you can see in the error itself that it shows the exact string you are expecting at the very end so nothing is translating it or editing it.
This is on a FRESH install in AWS. Errors happen in both Chrome and Edge (latest versions). If you add 'data:' to the policy, it corrects it. It is just a matter of missing information in the default config. If you add 'data:' to the CSP, it loads correctly. 'self' does not include 'data:' which is how the fonts are being loaded.
If you guys are using webpack by any chance for the build process, there is a known error in webpack.
-
Hello,
As of v69.0.8 we are seeing many failures due to Content Security Policy settings to load the fonts as well as numerous 404 errors for several js files. We have modified the templates as a short term fix.
Refused to load the font 'data:font/woff2;charset=utf-8;base64,d09GMgABAAAABPfYAAoAAAANDGgABPeLAwQBAA…3vVTy4JjPl3dW7rL/5M5q5e6D9CAVi9h+FdkMTe2kWWnqGdWT8TM66vW13xqSu5Kz/MgADAAA=' because it violates the following Content Security Policy directive: "font-src 'self' https://fonts.gstatic.com/".
DevTools failed to load source map: Could not load content for https://pbx.company.com/libraries/chartJs/chart.umd.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
Unchecked runtime.lastError: The message port closed before a response was received.
Unified Vodia Server Management System
in Integrators
Posted
Would love to check this out and even contribute to it if possible!