After a recent automatic update to linux components (CentOS v7 with PLesk 17.8.11) my web (php) applications are no longer enabled to do outbound connections.
Both "curl" requests and PHPMailer fail; curl is returning http code 0 with no content, while PHPMailer says "SMTP Connect() failed".
The same statements/programs work perfectly when run from terminal (root user). In other words, if I write a trivial program executing "curl http://www.example.com" and run it from terminal, it works; if I call it from a browser, it does not work.
The same is true for any program using PHPMailer to send a mail.
SELinux is disabled, so it does not depends on the httpd_can_network_connect SELinux boolean.
Any idea?
I found a solution, but I did not really understood what the real reason was. By default, my CentOS+Plesk server has SELinux disabled: I changed it to "enabled" with SELINUX=permissive, then I changed two SELinux booleans:
setsebool -P httpd_can_network_connect on
setsebool -P httpd_can_sendmail on
Even if SELinux is in warning-only mode, settings those two booleans on made the trick.
Most likely, affected domains are using system PHP, which was updated recently. Correct me if I am wrong.
What would explain broken PHP functionality, because during the update of system PHP package, Apache restart is not triggered by Plesk.
Simply restart Apache in Tools & Settings > Service Management or by using systemctl restart httpd. If the issue still persist after that, try to switch to any of Plesk PHP versions.
Related
I'm a little bit confused about https communication with influxdb. I am running a 1.8 Influxdb instance on a virtual machine with a public IP. It is an Apache2 server but for now I am not willing to use it as a webserver to display web pages to clients. I want to use it as a database server for influxdb.
I obtained a valid certificate from Let's Encrypt, indeed the welcome page https://datavm.bo.cnr.it works properly over encrypted connection.
Then I followed all the instructions in the docs in order to enable https: I put the fullchain.pem file in /etc/ssl directory, I set the file permissions (not sure about the meaning of this step though), I edited influxdb.conf with https-enabled = true and set the path for https-certificate and https-private.key (fullchain.pem for both, is it right?). Then, systemctl restart influxdb. When I run influxdb -ssl -host datavm.bo.cnr.it I get the following:
Failed to connect to https://datavm.bo.cnr.it:8086: Get https://datavm.bo.cnr.it:8086/ping: http: server gave HTTP response to HTTPS client
Please check your connection settings and ensure 'influxd' is running.
Any help in understanding what I am doing wrong is very appreciated! Thank you
I figured out at least a part of the problem. It was a problem related to permissions on the *.pem files. This thing looks weird because if I tip the following, as documentation says, it does not connect.
sudo chmod 644 /etc/ssl/<CA-certificate-file>
sudo chmod 600 /etc/ssl/<private-key-file>
If, instead, I tip the second line with 644 all works perfectly. But this way I'm giving to anyone the permission to read the private key! I'm not able to figure out this point.
UPDATE
If I put inside /etc/ssl/ the symlinks that point to the .pem files that live inside /etc/letsencrypt/live/hostname the connection is refused. Only if I put a copy of the files the ssl connection starts.
The reason I am willing to put the links inside /etc/ssl/ is the automatic renew of the certificates.
Anyone can help?
I've just done a fresh install of Ubuntu 20.04 and followed the Digital Ocean instructions to get my apache server up and running:
https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu-20-04
Which worked fine for HTTP traffic, then I used the Digital Ocean instructions (which I knew, but followed them anyway) to set up for SSL (https) access:
https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-20-04
I selected the option to redirect all traffic to https. I opened my firewall using sudo ufw allow 'Apache Full'.
But I am unable to see my sites - the browsers just timeout. I have tried disabling ufw just to see, and nope, nothing.
SSL Labs just gives me an "Assessment failed: Unable to connect to the server" error.
I also ran https://check-your-website.server-daten.de/?q=juglugs.com
and it timed out:
I have deleted the letsencrypt stuff and ran through it again three times with the same result, and now I'm stuck...
Everything I've searched points to a firewall error, but as I've said, I've disabled that and have the same result. The router settings have not been changed since I did my fresh Ubuntu install.
Any help gratefully received.
Thanks in advance.
on8tom answered this one for me - In setting up the new build of Ubuntu, my local IP address for the apache server had changed, and my Virgin Media Hub only had port 443 open to the old IP address.
Many thanks for pointing me at that (but I should have checked that before posting this - kicking myself!)
Just a bit of background first.
I have installed coturn server in my local machine (Behind a firewall and with local IP).
I have created a port forwarding for cotrun server lets say my local ip is: 192.168.0.11:3478 is mapped with my public ip 10.1.10.212:3478.
When I use some online utility to check my public IP has this port open it? that utility shows that it is open.
I am trying to test this server using this fiddle: Code to test TURN server
I removed the stun configuration from it, and added my live ip and port. And when I try to test it, it says your TURN server is broken in console on web browser. And I see failed as output.
I have also used following commands to create a user from this link.
Wiki to Coturn Configuration
// created test user
sudo turnadmin -a -u test -r test -p test
// enabling admin support in web (not sure how to access it in browser)
sudo turnadmin -A -u test -p test
I start the turn server using following command:
turnserver -L 192.168.0.11 -a -f -v -X -r test
I have enabled the "TURNSERVER_ENABLED"
/etc/default/coturn
TURNSERVER_ENABLED=1
Screenshot of my about:webrtc:
Please find the below attached Screen shot for my about:webrtc. I am not sure what is missing.
EDIT-1
I can also see the incoming packet message processed, error 401: Unauthorized in the console of TURN server
EDIT-2
I resolved the TURN server related issue, added the turn server in client code as well, still facing issue, call is not going through,
Update
Here is what I found, the reason why it wasn't working earlier was due to a defective router in the network. This thing has harassed me for almost a month (however the internet used to work fine). But I found that there is a loss of packets and I switch to LAN cable I even avoided the firewall of the organization and there it was working just fine. Then I configured the rules in firewall and it started working as well.
A few issues that might be causing this:
The -X option requires an argument - the external IP if the TURN server is behind a NAT.
If you are setting all your parameters on the command line, you should include -n to ensure that it does not load an unrelated configuration file.
TURNSERVER_ENABLED=1 is to start turnserver with default configuration at system boot. You do not want this if you are starting turnserver manually from the command line.
https://github.com/coturn/coturn/blob/master/README.turnserver
" I have created a port forwarding for CoTurn server lets say my local ip is: 192.168.0.11:3478 is mapped with my public ip 10.1.10.212:3478."
Now surely you are aware that the private address-spaces in IPV4 are (private IP ranges):
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
So, your first IP is in the last private IP range, and your so-called "public IP" is in the first private IP-range. Now you need to find your TRUE REAL public-IP address to try to connect to it from outside. I would say that it looks like your ISP has you behind a NAT. So your TURN server might be behind two NATs. Which is kind of ironic situation for a server designed to help penetrate NATs of webRTC-clients. You might want to try to put CoTurn somewhere where it is possible for it to work like AWS (special case of CoTurn friendly NAT).
Just recently got (well with lots of help -- that even did the most of the work) CoTurn to work in cloud and on local Ubuntu ;-) (never stopped me from bragging though). Though there is troubling few srflx-call-successes yet (mostly local network or relay(TURN) calls). :-D
I'm using Ansible to spin up a new Amazon EC2 install, and then I install Java and Tomcat (via the yum module). After placing the war for sample project from the Apache website in the webapps directory, I go and run the the command (below), nothing happens. It returns with response, no error. I've checked both the IP and port 8080 and Tomcat is not running.
[centos#sonar-test webapps]$ sudo systemctl start tomcat
[centos#sonar-test webapps]$ sudo systemctl start tomcat
[centos#sonar-test webapps]$
For reference, I was following this tutorial as well:
https://www.digitalocean.com/community/tutorials/how-to-install-apache-tomcat-7-on-centos-7-via-yum
From your comment on my question running curl in your ec2 instance
When I curl I get a large html document with various apache-esque things on it
It means Tomcat is installed and running.
If you don't access it, its because of your security group rules
In your ec2 console, select the Security Groups option. Edit the rules that is associated with your ec2 instance (the one running Tomcat) and permits inbound connections to port 8080 (so you can make request to your Tomcat server) and port 80 if you're running Apache (or nginx/another web server). If you're not sure about security, you can restrict the inbound traffic to come only from your IP so you can test but no-one else can make request.
I use Debian 8.0 running an Apache v.2.4.10 and I try to add the OpenID Connect module named libapach2-mod-auth-openidc version 1.6.0.
After installing the module, I enable it with the command: sudo a2enmod auth_openidc. This works fine and now I want to restart the Apache server with sudo service apache2 restart, which leads me to an error
"Job for apache2 failed. See 'systemctl status apache2.service' and 'journalctl -xn' for details."
The result of
systemctl status apache2.service
shows an error while starting the server, but no detailed information of the error (code=exited, status=1/FAILURE).
And the result of
journalctl -xn
tells, that there are no journals.
So if I am disabling the auth_openidc module, the Apache server starts again without problems.
Details of the Configuration:
Apache runs with its default settings. I did not change anything!
auth_openidc module was not changed by me neither at this time!
Can someone explain why Apache with the enabled auth_openidc module would not start anymore?
After installing libapache2-mod-auth-openidc you will have to configure some settings before the module can be used successfully. Two of the mandatory settings are OIDCRedirectURI and OIDCCryptoPassphrase. Most probably you'll also have to configure client credentials for your OpenID Connect provider. You can take a look at the sample configurations at: https://github.com/pingidentity/mod_auth_openidc#openid-connect-sso-with-google-sign-in
Errors/warnings about the missing configuration directives should be displayed in: /var/log/apache2/error.log
While we're at it, I would also advise you to use the latest version 1.8.1 from https://github.com/pingidentity/mod_auth_openidc/releases