Search results

The new certs wont be in after switching to doing subdomain, they will be in the directory named after the first domain in your domains list you provided do the letsencrypt script. Find the certs, and then update the sites-enabled conf ssl paths.

Your posts don't indicate that: If you took a look at the letsencrypt script, you would see that is uses the SED module to do a direct replacement of original default certs in nginx.conf - because you switched from one base domain to another, and you don't have the default strings in...

Once again, if it were me: At this point, I would see if your certs are being created, and then manually update the nginx.conf (and/or includes) with the new cert file names and manually start nginx to see if you get the same error.

It’s unclear whether these errors are happening when you manually start nginx or when you’re re-running the script. At this point, I would see if your certs are being created, and then manually update the nginx.conf (and/or includes) with the new cert file names and manually start nginx to see...

His problem isn't DNS... his problem is that the letsencrypt.sh script is not very good at dealing with changes to the original first domain in your list. He moved from a wildcard cert (which can't be automatically renewed without several more hoops... not stating it's impossible) to several...

You can certainly just try to edit them - if they point to files that exist, then nginx will probably start. Otherwise, if you remove them, nginx's conf validation might complain that you have NO cert specified... but that'd be the next step (remove the lines altogether). If you just look at...

/etc/nginx/nginx.conf Might have some references to '/etc/dehydrated/certs/mydomain.com/fullchain.pem', which may no longer be correct, since you have now moved from doing a wildcard to multiple explicit domains. Might have to clean up that nginx.conf file and rerun the letsencrypt.sh script to...

IIWM = If it were me YMMV = Your mileage may vary ASN = alternative subject name (a certificate construct that allows a single certificate to be valid for multiple domains) Not sure about the voicemail thing - be careful about assuming correlation. If you want to know why that's happening...

IIWM, I would clear out and then rerun the letsencrypt.sh script as instructed here. As stated above, my advice is that if you're going to start with multiple domains, start with at least two so that your first cert gets written with an alternate subject name- I had issues adding my first...

We're using dehydrated with multiple domains. I haven't set up a cron to auto-renew, so can't comment if that works, but I expect that it will, and the script sets everything up for TLS as well. I'm skeptical of going too far afield of what the devs have in mind for cert management, it starts...

This is a contradiction to the best of my knowledge: It would help to know what the contents of /etc/dehydrated/domains.txt; you can get it with: Does that file have a wildcard, one, or multiple domains? Post at your own discretion - it will contain your domains. The crontab you configured...

I was able to follow the docs. https://docs.fusionpbx.com/en/latest/getting_started/lets_encrypt.html One tip for your situation (as I was in the same): when you do your first request, make sure you do it with multiple domains, otherwise the initial and subsequent certs don't have alternate...

Well, after running down the list, it appears that removing the BLF for the Flows made it stop doing this. I'm using <param name="startup-script" value="blf_subscribe.lua flow"/> in lua.conf.xml in order to start the blf_subscribe.lua script. Not sure why the phone would react to that BLF as...

https://docs.fusionpbx.com/en/latest/status/email_queue.html#install-instructions Probably set it up as a Cron job and up the frequency on the cron job?

So, I have a couple T53Ws on my desk testing FusionPBX and all is going well for the most part. One behavior that I'm noticing that would drive me a bit crazy as a user is that the LCD screen on these phones occasionally wakes up from the screensaver/power save. Sometimes it happens at the same...

Considering the error on your CDR screenshot is 'no route destination', I once again feel like this is a dial plan not having a match for your dialed destination. I feel like you should review the documentation surrounding Routes and Dialplans, as well as understand regex (regular expression)...

Oh, your initial posts really made it seem like you had that part down pat. Glad you got it worked out. I have been very impressed with the provisioning in FusionPBX - the multiline ability is clean, so I agree your use case should be easily accomplished.

My advice would now be to move to the phone and manually set one of the keys to confirm if you can make it work that way. If you can, then do an export of the CFG from the phone and compare the BLF/DSS line key settings and make sure the provisioning file isn't malformed.

I had a theory that because the phone was a 16 line phone that it wouldn't allow provisioning line keys above key 16. I have some spare T53Ws on my desk for testing right now, so I tested that against them, but I was able to provision line keys higher than key 12 (T53s are 12-line), on up to the...

The inbound call isn’t matching any of your defined destinations. If it were me, I’d approach this by looking at the dial plan and seeing if it’s configured as such: ^\+?1?(nnnnnnnnnn)$ Where n is your phone number. This would mean that both the plus and the 1 preceding the number are optional.