I'm using BBB version 2.2.15 on Ubuntu 16.04. I'm facing issue with default presentation is not working.
I have default.pdf in /var/www/bigbluebutton-default/default.pdf as well. I could also see PDF getting uploaded in /var/bigbluebutton as well.
this issue happened after September,2021.
technical details is available in this link.
you can use another SSL provider or its better to replace BBB2.2.15 with BBB2.3 or BBB2.4
have you configured IPv6 correctly? I had the same problem because I hadn't entered IPv6 in the DNS settings.
In the DNS records, your domain must point to IPv4 and also to IPv6!
Related
I am trying to use the Fanuc Adapter found here https://github.com/mtconnect/adapter . And I've gotten this to compile and run on a machine with a Fanuc Controller. My problem is that it is giving me a result of -16 anytime I make a connection to it with an agent or through a web browser. I think the problem is that the machine is using an HSSB connection instead of ethernet and I have the wrong IP and Port. Yet everything online points to setting the IP to 127.0.0.1 and the default port to 8193, which I have tried. Does anyone know what could be the issue or how to set up a Fanuc Adapter on a controller with an HSSB connection? All the resources I've found only explain connecting via ethernet.
Figured it out. The adapter was always using a ethernet handle. Changed the source code to check and use both.
Both my device and the host through which i'm trying to access are in the same subnet.
Scenario:
I have a switch and a server in same subnet. I have to access switch using ipv6 link local address from the browser in my server.
Can anyone pls tell me the exact syntax??
To give an answer specific to browsers: for most common browsers, you can't.
There is a proposed standard format, as Sander Steffann pointed out, for specifying the interface for a URL, which is in RFC 6874.
The developers of both Chromium and Firefox, and seemingly most other browsers, have decided to intentionally not support this. Firefox has actually had ipv6 link-local support intentionally removed. Bug reports are closed as WONTFIX. See Chromium bug 70762, and Firefox bug 700999. Furthermore, WHATWG also rejected implementation of RFC 6874. This has been the case for years, so I doubt anything short of a patch or fork will result in link-local addresses working. It appears that a number of people are quite set on not allowing link-local address support.
One workaround, however, is to use SSH forwarding. For example,
ssh -L '8080:[FE80::XXXX:XXXX:XXXX:XXXX%wlp4s0]:80' localhost
A link local address can be valid on multiple links. If for example your system has both Ethernet and Wi-Fi those might be connected to different networks. Therefore you need to add a scope identifier to a link-local address. The syntax for that is to add % and the scope to the IPv6 address. The score is usually the name of the interface, for example eth0 or ens192 on Linux, or 13 on Windows. The value is different on each system, so you'll need to check what to use in your case.
That gives you for example fe80::1111:2222%eth0. The problem is that % has special meaning in URLs, so you need to escape it. The escape for % is %25.
The correct URL syntax is http://[fe80::1111:2222%25eth0]/. The official standard for this is RFC 6874. Unfortunately many browsers don't follow the standard, so it might not work for you. In that case please file a bug report. There need to be more people complaining to get this fixed.
For those who have no sshd server set up on their laptop and find it would be troublesome to set up one --- try finding port-forward scripts.
Here is a usable python script, without external dependencies.
https://gist.github.com/NeverBehave/357ca63941d4af4ee3f54920be3d1f3c
We are currently encountering the following error when trying to connect to a Cloud SQL instance: Lost connection to MySQL server at 'reading initial communication packet', system error: 0.
This is a familiar error, and as detailed here usually means the IP address needs to be whitelisted. However, we believe we have done so.
Is there a way to see connection attempts and their IP addresses that have been made (and refused) to the Cloud SQL instance?
Currently we don't expose that information but it is something we would like fix. :-)
According to #Razvan, as of September 2014, this information isn't exposed.
We ended up using CIDR blocks to search the space and find the actual IP address. This is unsatisfying, obviously, but it's a way to pin down the problem.
If other people want to sanity check that the problem is their IP is being refused, you can add 0.0.0.0/0 in order to accept all ranges and try to connect. If it works, you know what is the problem.
Be absolutely sure to remove this as an accepted range, after you are done, however!
Figured I might help someone who stumbles here.
Had exactly the same issue essentially trying to connect to a GCP SQL instance from a hosting provider.
Whitelist the IP address that is shown in my cpanel and it will not connect. (It used to, but the provider made some changes with their infrastructure lately and it stopped working)
put 0.0.0.0/0 in my Cloud Platform whitelist and it connects no problem.
So now I know that my cpanel IP is not the IP trying to connect to GCP.
After some hair pulling (figured that the bare metal server had a different IP than my cpanel IP, it did, but this also didn't work.)
finally tried the IP address for the name servers that point to my domain and bam. All is good.
If you are facing this issue, try your name server (usually something like NS1.hostingprovider.com etc..). I put both the NS1 and NS2 ip's in the whitelist and we are working fine.
I am trying to bind a HttpWebRequest call to a specific IP on my server (which has many IPs). I have successfully written this code using BindIPEndPointDelegate and it works well on my local machine (Windows 7)
My issue is with Windows Server 2008. When I run the same console app on Windows Server 2008 it fails to bind to the IP when using the delegate. To complicate matters further, it seems to work for some destination URLs (http://www.microsoft.com) and doesn't work for some (http://www.google.com, http://www.facebook.com)
If I remove the IP specific binding (delegate) and run the app it works for all URLs.
The IP I am binding to is the default server IP address - meaning, in both scenarios the same IP should be used. I have verified this and it uses the same IP if I don't bind using the delegate. If I explicitly specific the IP it fails as described above.
I have tried turning off firewall, IIS & Antivirus - the problem persists.
Alright finally figured it out.
Upon testing again I found that specifying IPAddress.Any did not work either. On the other hand, IPAddress.IPv6Any worked fine.
Finally, I unchecked the IPv6 protocol in network adapter settings and the app starting working properly for all URLs and binding for all local IPv4 addresses.
Not sure if this is a bug in .NET code or feature - but disabling IPv6 fixed it for me.
Lastly, if anyone is facing "The requested address is not valid in its context" while making calls with binding, try disabling your antivirus.
I'm using exim on both the sending and relay hosts, the sending host seems to offer:
HELO foo_bar.example.com
Response:
501 Syntactically invalid HELO argument(s)
Possibly a problem with underscores in the hostname?
http://www.exim.org/lurker/message/20041124.113314.c44c83b2.en.html
Underscores aren't actually valid in internet host names, despite some people using them anyway. A sane DNS server should not allow you to have records for them.
Change your system's host name so it's valid, hopefully this will fix it.
After spending so many hours trying to fix this problem, which in my case just come up from nothing, I ended up with a solution. In my case, only the systems deployed to Suse OSs suddenly stopped sending emails but not those ( the same ) running on Ubuntu. After exhausting and eliminating all the suggested possibilities of this problem and even considering to change de OS of those machines, I found out that somehow the send email service is sensible to the hostname of the host machine. In the Ubuntu machines the file /etc/hosts have only the following line:
127.0.0.1 localhost
and so were the Suse machines, which stopped sending the emails. After editing the /etc/hosts from Suse machines to
127.0.0.1 localhost proplad
where proplad is the hostname of the machine, the errors were vanished. It seems that some security policy ( maybe from the smtp service ) uses the hostname information carried through the API, which was being ignored in the case of the Ubuntu machines, but not in the case of Suse machines. Hope this helps others, avoiding massive hours of research over the internet.
Diago's answer helped me solve the problem I have been trying to figure out.
Our Suse OS also stopped working out of nowhere. Tried every suggestion that I found here and on google. Nothing worked. Tried adding our domain to etc/hosts but that did not help.
Got the hostname of server with the hostname command. Added that hostname to the etc/hosts file just like Digao suggested.
127.0.0.1 localhost susetest
I saved the changes, then ran postfix stop, postfix start. And works like a charm now.
The argument to HELO should be a hostname or an IP address. foo_bar.example.com is neither an IP address nor a hostname (underscores are illegal in hostnames), so the error message is correct and there is nothing to fix.
Using qmail I came across this problem. I realised this was because of a previously unfinished installation.
1) When sending email qmail announces itself to other SMTP servers with "HELO ..." and then it adds what is in the file at: /var/qmail/control/me
(sometimes the file is located at /var/qmail/control/helohost)
2) This file should have a hostname with a valid DNS entry in.
Mine did not it had (none) which is why mails were failing to be sent.
I found that my local dev server suddenly stopped sending emails (using external SMTP) and on the server logs I found:
rejected EHLO from cpc96762-*******.net [..**.68]: syntactically invalid argument(s): 127.0.0.1:8888/app_dev.php
127.0.0.1:8888/app_dev.php is my local URL, I am using Docker, Symfony and Swift Mailer.
The only solution that helped in my case was adding the parameter:
local_domain = "localhost"
to my Swift Mailer configuration. That solved all the problems.
See the docs for the Swift Mailer local_domain option: https://symfony.com/doc/current/reference/configuration/swiftmailer.html#local-domain