PERL_LWP_SSL_VERIFY_HOSTNAME setting to 0 is not working - perl

Am running into an issue connecting on a Ubuntu machine while my other machine works fine. The difference between both is the Ubuntu version and the SSLeay version but i can't narrow down what the issue is.
I already did the following:
a) add the environment variable: PERL_LWP_SSL_VERIFY_HOSTNAME with a value of 0
b) add the $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0; to the VICommon.pm file
Both the above ones didn't work. I can't figure out why it doesn't work on my second machine.
Ubuntu 12.10 (Works)
$perl /usr/lib/vmware-vcli/apps/general/connect.pl --url https:///sdk/webService --username --password
Connection Successful
Server Time : 2013-07-19T22:11:31.681181Z
$ perl -v
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi
$ perl -MLWP -e 'print "LWP Version: $LWP::VERSION\n"'
LWP Version: 6.04
$ perl -MCrypt::SSLeay -e 'print "Crypt::SSLeay Version: $Crypt::SSLeay::VERSION\n"'
Crypt::SSLeay Version: 0.58
Ubuntu 13.04 (Doesn't work)
$perl /usr/lib/vmware-vcli/apps/general/connect.pl --url https:///sdk/webService --username --password
Server version unavailable at 'https:///sdk/vimService.wsdl' at /usr/share/perl/5.14/VMware/VICommon.pm line 548.
$ perl -v
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi
$ perl -MLWP -e 'print "LWP Version: $LWP::VERSION\n"'
LWP Version: 6.04
$ perl -MCrypt::SSLeay -e 'print "Crypt::SSLeay Version: $Crypt::SSLeay::VERSION\n"'
Crypt::SSLeay Version: 0.64
Certificate error (same in both machines)
lwp-request https:///sdk/webService
Can't connect to :443 (certificate verify failed)
LWP::Protocol::https::Socket: SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/share/perl5/LWP/Protocol/http.pm line 51.
UPDATE 1
Looks like the issue has nothing to do with the Ubuntu version but the new packages i get when i do 'apt-get upgrade', on the 12.10 box i didn't do that and it was working. However on 13.04 i ended up doing all the updates. Now since i get more than 80 updates when i did i still haven't narrowed down to the library which is messing it up. When i installed a new 13.04 image it works fine.
** Update 2 **
Looks like the base Ubuntu 12.10 or 13.04 work fine. If you get the latest updates then it stops working. So not sure yet which library is causing the problem.

I have had the very same problem - I solved it by typing "use Net::SSL;" before the requests.
Also tried to find out what library is causing the problem because it's definately an upgraded module that is causing it. Most sites were okay though, but one site's certificate wouldn't validate.

Rather than using use Net::SSL; soon in your code, you can achieve more predictable behavior with:
$ENV{PERL_NET_HTTPS_SSL_SOCKET_CLASS} = 'Net::SSL';
And now PERL_LWP_SSL_VERIFY_HOSTNAME set to zero will work as expected. But changing the underlying implementation module should not be considered as solution, but a hack.

It also can depend on the version of Net::HTTPS, and on whether or not IO::Socket::SSL is installed. Net::HTTPS will prefer IO::Socket::SSL (which uses Net::SSLeay) over Net::SSL (which uses Crypt::SSL). More recent versions of Net::HTTPS have improved how it works with IO::Socket::SSL.

You can try to add Global ENV variable or set in via Apache config (if you're using Apache)
SetEnv PERL_LWP_SSL_VERIFY_HOSTNAME 0
or
$ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;

Setting the PERL_LWP_SSL_VERIFY_HOSTNAME env var to 0 will disable important security checks.
Upgrading the relevant modules to the latest version (as of November 2014) fixed the problem for me.
(In my case I updated to these distributions: Crypt-SSLeay-0.72, Net-HTTP-6.07, libwww-perl-6.08 LWP-Protocol-https-6.06.)

Related

How do i fix PDOException::("SQLSTATE[08006] [7] SCRAM authentication requires libpq version 10 or above") [duplicate]

I am getting an error after moving the project to production. The error is as follows while running with production server
pg_connect(): Unable to connect to PostgreSQL server: SCRAM
authentication requires libpq version 10 or above.
Here is my PostgreSQL version:
Development Version :
PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623
(Red Hat 4.8.5-36), 64-bit
Production Version :
PostgreSQL 11.5 (EnterpriseDB Advanced Server 11.5.12) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
For those on M1-Based macs who are currently seeing this issue in docker - there appears to a bug upstream in libpg that's building against the wrong library version on ARM.
Until it's fixed, a workaround is to (at a performance hit) is to just run it via rosetta.
export DOCKER_DEFAULT_PLATFORM=linux/amd64, and re-build your images.
You'll get the latest version of libpq, and things should Just Work.
Ref: https://github.com/psycopg/psycopg2/issues/1360
Your application uses an API that is linked with the PostgreSQL client C library libpq.
The version of that library must be 9.6 or older, and SCRAM authentication was introduced in v10.
Upgrade libpq on the application end and try again.
If you don't need scram-sha-256 authentication, you can revert to md5:
set password_encryption = md5 in postgresql.conf
change the authentication method to md5 in pg_hba.conf
reload PostgreSQL
change the password of the user to get an MD5 encrypted password
I ran into this while running a python:3.9 docker image where I had installed psycopg2-binary==2.9.3. Installing psycopg2==2.9.3 instead resolved it for me.
For Amazone linux users:
$ sudo yum install -y amazon-linux-extras
then re install the postgres client again
$ sudo amazon-linux-extras install postgresql10
Then the main part install the python package in my case it was (psycopg2) reinstall it
$ pip3 install --force-reinstall psycopg2==2.93
specification:
python3.8.9
I used to get an error SCRAM authentication requires libpq version 10 or above when running php artisan migrate in laravel 8. Then I fixed it as follows: Change authentication from scram-sha-256 to md5, then reset your password and restart the postgresql-x64-13 service and here are step by step:
Step 1: Find file postgresql.conf in C:\Program Files\PostgreSQL\13\data then set password_encryption = md5
Step 2: Find file pg_hba.conf in C:\Program Files\PostgreSQL\13\data then change all METHOD to md5
Step 3: Open command line (cmd,cmder,git bash...) and run psql -U postgres then enter your password when installed postgres sql
Step 4: Then change your password by run ALTER USER postgres WITH PASSWORD 'new-password' in command line
Final: Restart service postgresql-x64-13 in your Service.
If you want to keep the scram-sha-256 for security. You need to update your client postgreSQL libraries, due to php-pgsql default version does not support it.
CentOS/Rhel/Rocky
yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
yum install postgresql13
This will update the server/client libpq in order to keep using scram-sha-256
This issue still affects m1 macs running python:3.10.* docker containers (based off aarch64 Debian 11). Solution for me was to install psycopg2 (build from source) instead of psycopg2-binary which is advised for production anyways:
pip install psycopg2
The python container has all the build dependencies already (like gcc). A more production appropriate container most likely won't have these https://www.psycopg.org/docs/install.html#build-prerequisites
I find 2 solutions. I didn't try local, solutions are for docker container.
Preliminary information:
According to the main image we defined at the beginning of the Dockerfile, our libq versions may differ. It is explained with examples in the answer given here.
If you want to know your libq version used in your docker-image, you can do the following, respectively.
After docker-compose run
docker-compose exec <app_name_in_docker-compose_file> sh
python
import psycopg2
print(psycopg2.extensions.libpq_version())
If you're getting an error, you'll probably see a number like 90xxx here.
Solutions:
First basic one. I used 'python:3.9-slim-buster' at docker and I've got error. Change base image name to 'python:3.9.6-alpine3.14'
The second solution is to build the psycopg2 file and install libq and other dependencies. For this, add the following commands to the dockerfile.
RUN apt update -y && apt install -y build-essential libpq-dev
RUN pip3 install psycopg2-binary --no-binary psycopg2-binary
All the answers that are suggesting that password encryption should be reverted back to md5 are forgetting that PostgreSQL changed its default password encryption from md5 to scram-sha-256 for security reasons.
The issue then is those client applications that fail to use this modern encryption method. The libpq file that ships with PostgreSQL version 10 and above is fine. Just change your client applications if you can so that you use only the ones that support this new method.
For instance, For a long time I was using a package called RPostgreSQL that allows users to connect to a PostgreSQL database from R. Turns out that package doesn't support scram-sha-256. I have now replaced it with its modern equivalent called rpostgres. Problem solved, everybody happy now!
Based on answer by #meijsermans, I changed the requirements.txt for django:
#psycopg2-binary>=2.9.3
psycopg2>=2.9.5
and it worked without the SCRAM error!
Also tried with and without platform: linux/arm64 in docker.compose, didn't solve the problem.
Tried platform: linux/amd64 and had some unrelated errors (mainly "exec /bin/sh: exec format error")
Using postgres:14.5 image in postgres container and python:3.10.7 image for django
Had this issue and fixed it by switching from the binary version of psycopg2 to psycopg2 = "^2.9.3"
Thanks to previous answers, this was resolved in my case too when I switched from psycopg2-binary to psycopg2.
Use pip install psycopg2 in your environment. This resolves the issue for ubuntu based systems.
Encountered the same issue and applied #Laurenz Albe's fix but I would get an authentication error on my user for the database, because of encryption strategy change.
So instead of replacing scram-sha-256 with md5, replace it with trust in pg_hba.conf
Here is a more mundane answer, but this is what happened to me so I'll add it here.
I got this error when I tried to start PostgreSQL 9.4. I realized I already had PostgreSQL 11 running - it started automatically with my computer. Once I stopped version 11, I was able to start version 9.4. They can't listen on a port already in use, and both had the same port set. But I'm not sure exactly why the misleading error wording.
Found this problem installing on a ubuntu 22.04 image with python3.10 on Mac M1.
What worked for me was installing the psycopg2 package as root rather than with --user - then the specific user can use the package.
Looks like the --user install puts an incorrectly linked libpq at
/home/<user...>/.local/lib/python3.10/site-packages/psycopg2_binary.libs/libpq-d97d8807.so.5.9
If you have another pip install --user process kicking about after this, and it installs psycopg2 again under the .local path, just remove that from .local/lib/python3.x/site-packages/psycopg2*
Use vi (or other editor) to replace scram-sha-256 with md5 in the file postgresql.conf and post_hba.conf ; location of the files depends on your local set up. After this step 1 you may (most likely) continue to have the issue of authentication error. This is bcos the hash of password in DB still uses scram encryption. We will solve in the next few steps.
Restart postgresql server. This command depends on your server setup as well.
Reload DB and verify. Login with postgres id: sudo -u postgres sql
Reload (under the psql console):
SELECT pg_reload_conf();
Check Encryption:
SHOW password_encryption;
SELECT * FROM pg_hba_file_rules();
Reset password for user account (within the psql consol). This step will flush a new hash for the password under md5 to replace the existing scram hash of the user password.
\password user_id
Then you can run a test of DB connection with psycopg2, as well as sqlalchemy.
This solves my problem in the way i can understand, being aware that md5 is less ideal an encryption method than scram-sha-256 but recompile the package to meet the requirement of psycopg2 is a pain in a**. So i would switch back to md5 first then when the package are all ready then change it to scram encryption.
Reference: PostgreSQL downgrade password encryption from SCRAM to md5
RUN apt-get -y update \
&& apt-get install -y build-essential gettext libpq-dev\
&& apt-get install -y wkhtmltopdf\
&& apt-get install -y gdal-bin\
&& apt-get install -y libgdal-dev\
&& apt-get install -y --no-install-recommends software-properties-common\
&& apt-add-repository contrib\
&& apt-get update
Try this.

How can I solve Postgresql SCRAM authentication problem?

I am getting an error after moving the project to production. The error is as follows while running with production server
pg_connect(): Unable to connect to PostgreSQL server: SCRAM
authentication requires libpq version 10 or above.
Here is my PostgreSQL version:
Development Version :
PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623
(Red Hat 4.8.5-36), 64-bit
Production Version :
PostgreSQL 11.5 (EnterpriseDB Advanced Server 11.5.12) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
For those on M1-Based macs who are currently seeing this issue in docker - there appears to a bug upstream in libpg that's building against the wrong library version on ARM.
Until it's fixed, a workaround is to (at a performance hit) is to just run it via rosetta.
export DOCKER_DEFAULT_PLATFORM=linux/amd64, and re-build your images.
You'll get the latest version of libpq, and things should Just Work.
Ref: https://github.com/psycopg/psycopg2/issues/1360
Your application uses an API that is linked with the PostgreSQL client C library libpq.
The version of that library must be 9.6 or older, and SCRAM authentication was introduced in v10.
Upgrade libpq on the application end and try again.
If you don't need scram-sha-256 authentication, you can revert to md5:
set password_encryption = md5 in postgresql.conf
change the authentication method to md5 in pg_hba.conf
reload PostgreSQL
change the password of the user to get an MD5 encrypted password
I ran into this while running a python:3.9 docker image where I had installed psycopg2-binary==2.9.3. Installing psycopg2==2.9.3 instead resolved it for me.
For Amazone linux users:
$ sudo yum install -y amazon-linux-extras
then re install the postgres client again
$ sudo amazon-linux-extras install postgresql10
Then the main part install the python package in my case it was (psycopg2) reinstall it
$ pip3 install --force-reinstall psycopg2==2.93
specification:
python3.8.9
I used to get an error SCRAM authentication requires libpq version 10 or above when running php artisan migrate in laravel 8. Then I fixed it as follows: Change authentication from scram-sha-256 to md5, then reset your password and restart the postgresql-x64-13 service and here are step by step:
Step 1: Find file postgresql.conf in C:\Program Files\PostgreSQL\13\data then set password_encryption = md5
Step 2: Find file pg_hba.conf in C:\Program Files\PostgreSQL\13\data then change all METHOD to md5
Step 3: Open command line (cmd,cmder,git bash...) and run psql -U postgres then enter your password when installed postgres sql
Step 4: Then change your password by run ALTER USER postgres WITH PASSWORD 'new-password' in command line
Final: Restart service postgresql-x64-13 in your Service.
If you want to keep the scram-sha-256 for security. You need to update your client postgreSQL libraries, due to php-pgsql default version does not support it.
CentOS/Rhel/Rocky
yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
yum install postgresql13
This will update the server/client libpq in order to keep using scram-sha-256
This issue still affects m1 macs running python:3.10.* docker containers (based off aarch64 Debian 11). Solution for me was to install psycopg2 (build from source) instead of psycopg2-binary which is advised for production anyways:
pip install psycopg2
The python container has all the build dependencies already (like gcc). A more production appropriate container most likely won't have these https://www.psycopg.org/docs/install.html#build-prerequisites
I find 2 solutions. I didn't try local, solutions are for docker container.
Preliminary information:
According to the main image we defined at the beginning of the Dockerfile, our libq versions may differ. It is explained with examples in the answer given here.
If you want to know your libq version used in your docker-image, you can do the following, respectively.
After docker-compose run
docker-compose exec <app_name_in_docker-compose_file> sh
python
import psycopg2
print(psycopg2.extensions.libpq_version())
If you're getting an error, you'll probably see a number like 90xxx here.
Solutions:
First basic one. I used 'python:3.9-slim-buster' at docker and I've got error. Change base image name to 'python:3.9.6-alpine3.14'
The second solution is to build the psycopg2 file and install libq and other dependencies. For this, add the following commands to the dockerfile.
RUN apt update -y && apt install -y build-essential libpq-dev
RUN pip3 install psycopg2-binary --no-binary psycopg2-binary
All the answers that are suggesting that password encryption should be reverted back to md5 are forgetting that PostgreSQL changed its default password encryption from md5 to scram-sha-256 for security reasons.
The issue then is those client applications that fail to use this modern encryption method. The libpq file that ships with PostgreSQL version 10 and above is fine. Just change your client applications if you can so that you use only the ones that support this new method.
For instance, For a long time I was using a package called RPostgreSQL that allows users to connect to a PostgreSQL database from R. Turns out that package doesn't support scram-sha-256. I have now replaced it with its modern equivalent called rpostgres. Problem solved, everybody happy now!
Based on answer by #meijsermans, I changed the requirements.txt for django:
#psycopg2-binary>=2.9.3
psycopg2>=2.9.5
and it worked without the SCRAM error!
Also tried with and without platform: linux/arm64 in docker.compose, didn't solve the problem.
Tried platform: linux/amd64 and had some unrelated errors (mainly "exec /bin/sh: exec format error")
Using postgres:14.5 image in postgres container and python:3.10.7 image for django
Had this issue and fixed it by switching from the binary version of psycopg2 to psycopg2 = "^2.9.3"
Thanks to previous answers, this was resolved in my case too when I switched from psycopg2-binary to psycopg2.
Use pip install psycopg2 in your environment. This resolves the issue for ubuntu based systems.
Encountered the same issue and applied #Laurenz Albe's fix but I would get an authentication error on my user for the database, because of encryption strategy change.
So instead of replacing scram-sha-256 with md5, replace it with trust in pg_hba.conf
Here is a more mundane answer, but this is what happened to me so I'll add it here.
I got this error when I tried to start PostgreSQL 9.4. I realized I already had PostgreSQL 11 running - it started automatically with my computer. Once I stopped version 11, I was able to start version 9.4. They can't listen on a port already in use, and both had the same port set. But I'm not sure exactly why the misleading error wording.
Found this problem installing on a ubuntu 22.04 image with python3.10 on Mac M1.
What worked for me was installing the psycopg2 package as root rather than with --user - then the specific user can use the package.
Looks like the --user install puts an incorrectly linked libpq at
/home/<user...>/.local/lib/python3.10/site-packages/psycopg2_binary.libs/libpq-d97d8807.so.5.9
If you have another pip install --user process kicking about after this, and it installs psycopg2 again under the .local path, just remove that from .local/lib/python3.x/site-packages/psycopg2*
Use vi (or other editor) to replace scram-sha-256 with md5 in the file postgresql.conf and post_hba.conf ; location of the files depends on your local set up. After this step 1 you may (most likely) continue to have the issue of authentication error. This is bcos the hash of password in DB still uses scram encryption. We will solve in the next few steps.
Restart postgresql server. This command depends on your server setup as well.
Reload DB and verify. Login with postgres id: sudo -u postgres sql
Reload (under the psql console):
SELECT pg_reload_conf();
Check Encryption:
SHOW password_encryption;
SELECT * FROM pg_hba_file_rules();
Reset password for user account (within the psql consol). This step will flush a new hash for the password under md5 to replace the existing scram hash of the user password.
\password user_id
Then you can run a test of DB connection with psycopg2, as well as sqlalchemy.
This solves my problem in the way i can understand, being aware that md5 is less ideal an encryption method than scram-sha-256 but recompile the package to meet the requirement of psycopg2 is a pain in a**. So i would switch back to md5 first then when the package are all ready then change it to scram encryption.
Reference: PostgreSQL downgrade password encryption from SCRAM to md5
RUN apt-get -y update \
&& apt-get install -y build-essential gettext libpq-dev\
&& apt-get install -y wkhtmltopdf\
&& apt-get install -y gdal-bin\
&& apt-get install -y libgdal-dev\
&& apt-get install -y --no-install-recommends software-properties-common\
&& apt-add-repository contrib\
&& apt-get update
Try this.

uWSGI Fails with No module named encoding Error

I am trying to setup uWSGI with Pyramid, but I am getting this error, when attempting uwsgi --ini-paste development.ini
Python version: 3.2.3
Error message:
uwsgi socket 0 bound to UNIX address /tmp/uwsgi.sock fd 3
Python version: 3.2.3 (default, Oct 19 2012, 20:08:46) [GCC 4.6.3]
Set PythonHome to /root/path/to/virtualenv
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ImportError: No module named encodings
Here is what I have in development.ini
[uwsgi]
socket = /tmp/uwsgi.sock
master = true
processes = 4
harakiri = 60
harakiri-verbose = true
limit-post = 65536
post-buffering = 8192
daemonize = ./uwsgi.log
pidfile = ./pid_5000.pid
listen = 256
max-requests = 1000
reload-on-as = 128
reload-on-rss = 96
no-orphans = true
log-slow = true
virtualenv = /root/path/to/virtualenv
I suppose I have checked everything possible, including the following
echo LANG:$LANG LC_CTYPE:$LC_CTYPE
LANG:en_US.UTF-8 LC_CTYPE:
I am using virtualenv and uWSGI was installed while the environment was active. I have also checked that my virtual environment's lib has a package named encoding (pointing to my main python3.2 installation)
I have also checked this answer and this
I had previously installed uWSGI when my virtualenv was not active, but then I installed it properly and removed the executable and py files from previous installation.
Is there a way to get detailed logs, please let me know if there is.
Thanks in advance
Check that
virtualenv = /root/path/to/virtualenv
points to the right path.
I solved my error by fixing this mistyped path.
in my case it was basically because I used python 2.7 as main interpreter, and uwsgi choose pyhon3 plugin. You might need to force it using:
plugins=python32
where python32is appropriate name for your pythhon3 plugin.
Have you checked this: uwsgi python3 plugin doesn't work?
Just had the same problem. What I realized afterwards was that I installed uwsgi with pip install uwsgi in the virtualenv. Once I left the virtualenv, I installed uwsgi on the local system with
pip3 install uwsgi (notice I wrote pip instead of pip3). So I uninstalled with pip3 uninstall uwsgi and I repeated with pip install uwsgi. Worked like a Charm.
I also met this problem today, and I tried to set plugins=python34, but it did not work on Ubuntu 14.04 and Python 3.4.3
This is what I did to fix it:
sudo pip uninstall uwsgi
something goes wrong when i run sudo pip install uwsgi, and run this first:
sudo apt-get install python-dev
(sudo)pip install uwsgi
Run uwsgi command (with your options) just like the following line:
/<path-to-your-virtualenv-bin>/uwsgi --http :8008 --module project.wsgi --venv /<path-to-your-virtualenv> --chdir /<path-to-your-project>
You will find the issues.
Did you miss your module param?
I encountered a similar error message, but with a python version variation:
Python version: 3.4.3 (default, Nov 28 2017, 16:44:58) [GCC 4.8.4]
This came about from trying to use a python3.6 virtual environment, but uwsgi being setup for python3.4. I re-setup the virtual environment using python3.4 and all was well.
I had similar problem. In my case, the problem was in uid, guid params of uwsgi.ini. www-data user didn't have a permission to run python in virtualenv.
Building upon Edward's answer, I instead reinstalled uWSGI with pip3.6 instead of pip3, Python 3.4.8 being the default Python 3 on the server:
$ python3 --version
Python 3.4.8
Check the path of virtualenv. Make sure you are not using something like this: ~/.virtualenvs/xxx.
The ~ symbol points to the home directory of a user. So with different users, this path will refer to different positions.
If you are not very assured, please move the virtualenv to places like /home/.virtualenvs.

Starman and MovableType 5.2

MovableType 5.2 has builtin PSGI support (via a mt.psgi in the main directory) and I've been trying to take advantage of it using starman/plackup.
Starman w/ MT fires up, but I get odd Not Founds and a silent hang & fail when I run mt-upgrade.cgi.
How I am running starman:
cd /home/ec2-user/mysite/perl/components/movabletype
plackup -s Starman --port 8045 --error-log /home/ec2-user/mysite/perl/logs/starman.log --pid /home/ec2-user/mysite/perl/var/starman.pid -a mt.psgi
Mystery 1: My browser returns "Not Found" for index.html, but mt-static and mt.cgi is reachable.
X http://mysite:8045/mt/index.html ... Not Found
✓ http://mysite:8045/mt-static ... listing of static assets
✓ http://mysite:8045/mt/mt.cgi ... redirects to ...
X http://mysite:8045/mt/mt-upgrade.cgi?__mode=install ... fails
Mystery 2: Due to the redirect I believe that MT code is running. But it is mostly silent in the starman log even though I have tried different MT debug options. Worse, the mt-upgrade.cgi seems to be reached then fails with this lone message to the starman log:
[mypid] Bootstrap CGI script in non-buffering mode: /home/ec2-user/mysite/perl/components/movabletype/mt-upgrade.cgi
This non-buffering message seems informational and normal, and is coming from the MT codebase.
I have also run directly under starman and get the same result.
Any ideas or help would be appreciated!
System/Environment:
MT_HOME='/home/ec2-user/mysite/perl/components/movabletype'
linux AMI on an amazon ec2.
perl-5.16.0 under perlbrew.
CPAN modules:
cpanm starman
cpanm CGI::PSGI
cpanm CGI::Parse::PSGI
cpanm CGI::Compile
yum install expat-devel
cpanm XML::Parser
cpanm SOAP::Lite
cpanm SOAP::Transport::HTTP
cpanm XMLRPC::Transport::HTTP::Plack
cpanm DBI
sudo yum install postgresql9-devel
cpanm DBD::Pg
cpanm Task::Plack
MT config:
CGIPath http://mysite:8045/mt
StaticWebPath http://mysite:8045/mt-static
PIDFilePath /home/ec2-user/mysite/perl/var/starman.pid
DebugMode 1
ObjectDriver DBI::postgres
Database db
DBUser dbuser
DBPassword dbpass
DBHost dbhost.mysite
I'm Yuji Takayama, lead engineer of Movable Type. I did try to reproduce your steps but I was not able to reproduce this. (this means I got initial install screen)
So, Can you try with mysql? also can you try "tools/upgrade" script? I think you can get error messages when some errors occurs.
ex.)
cd MT_HOME; perl -Ilib -Iextlib tools/upgrade --username --password --nickname --email --preferred_language --site_name --site_url --site_path --site_theme --site_timezone
And, I have answer about "index.html was not found".
Reason: MT will never mount MT_HOME as static files directory like a mt_static, because we think that MT_HOME must not be possible to list.
If you are trying to run Movable Type under Starman, I would seriously recommend running the upgrade script that comes with Movable Type using the command-line equivalent of your choice. There is no good reason for mt-upgrade.cgi to become persistent in the manner that Starman and Plack permit.
Try to change your paths in mt-config.cgi to relative paths, not URLs. Like so:
CGIPath /mt/
StaticWebPath /mt-static/
Just curious: although it does work now, are you aware that PG isn't supported and that you're taking a risk that a future version of MT might break with it?
P.S. also don't forget the PIDFilePath directive mentioned in the documentation.
BTW, a 404 on http://mysite:8045/mt/index.html looks quite normal. You're not supposed to have your site index at the same level than MT (you could, but that's not the recommended setup and it won't work in a stock MT install that assumes that MT and the produced sites are clearly separated).

Omniauth Facebook Error - Faraday::Error::ConnectionFailed

(FYI: I'm following the Twitter Omniauth from railscast #241. I used Twitter successfully, now going onto Facebook)
As soon as I logged into Facebook using Omniauth, I get this error:
Faraday::Error::ConnectionFailed
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
What does this mean?
This is my code
Rails.application.config.middleware.use OmniAuth::Builder do
provider :facebook, '<key from fb>', '<another key from fb>'
end
There's actually nothing much in my code, all I have is in the sessionController that I want to use to_yaml to see what's inside the request.env
class SessionsController < ApplicationController
def create
raise request.env["omniauth.auth"].to_yaml
end
end
How do I solve the Faraday error?
I've fixed this on Mac OS X Lion 10.7.4 with this solution:
$ rvm remove 1.9.3 (or whatever version of ruby you are using)
$ rvm pkg install openssl
$ rvm install 1.9.3 --with-openssl-dir=$rvm_path/usr
after this you will need to download the missing cacert.pem file:
$ cd $rvm_path/usr/ssl
$ sudo curl -O http://curl.haxx.se/ca/cacert.pem
$ sudo mv cacert.pem cert.pem
You are getting this error because Ruby cannot find a root certificate to trust.
Fix for Windows: https://gist.github.com/867550
Fix for Apple/Linux: http://martinottenwaelter.fr/2010/12/ruby19-and-the-ssl-error/ <--This site is now down.
Here is the Apple/Linux fix according the site above:
The solution is to install the curl-ca-bundle port which contains the same root certificates used by Firefox:
sudo port install curl-ca-bundle
and tell your https object to use it:
https.ca_file = '/opt/local/share/curl/curl-ca-bundle.crt'
Note that if you want your code to run on Ubuntu, you need to set the ca_path attribute instead, with the default certificates location /etc/ssl/certs.
In the end, that’s what will work on both Mac OS X and Ubuntu:
require 'net/https'
https = Net::HTTP.new('encrypted.google.com', 443)
https.use_ssl = true
https.verify_mode = OpenSSL::SSL::VERIFY_PEER
https.ca_path = '/etc/ssl/certs' if File.exists?('/etc/ssl/certs') # Ubuntu
https.ca_file = '/opt/local/share/curl/curl-ca-bundle.crt' if File.exists('/opt/local/share/curl/curl-ca-bundle.crt') # Mac OS X
https.request_get('/')
Andrei's answer didn't work for me on Mac OSX 10.8.3. I had reinstalled openssl to install ruby 2.0 some time ago and since then always got this error. I fixed it thanks to Andrei's answer and instructions from the Rails project.
I ran:
$ rvm -v
$ rvm get head
# Installation of latest version of rvm...
$ rvm -v
# rvm 1.19.5 (master)
$ rvm osx-ssl-certs status all
# Certificates for /usr/local/etc/openssl/cert.pem: Old.
# Certificates for /Users/mpapis/.sm/pkg/versions/openssl/0.9.8x/ssl/cert.pem: Old.
$ sudo rvm osx-ssl-certs update all
# Updating certificates...
Then I checked if the certificates were correctly updated by running rvm osx-ssl-certs status all again but /usr/local/etc/openssl/cert.pem was still not updated. I don't know if that was necessary but I did the following:
$ cd /usr/local/etc/openssl/
$ curl -O http://curl.haxx.se/ca/cacert.pem
$ mv cacert.pem cert.pem
After that the problem was fixed. Hope that helps someone else who runs into the same issue.
this worked for me (on Mac OS X):
$ brew install curl-ca-bundle
$ export SSL_CERT_FILE=/usr/local/opt/curl-ca-bundle/share/ca-bundle.crt
Alternative Solution:
[I am Win7 user with manual install the Ruby and Ruby on Rails]
I have the same problem but cannot resolve by the answer that given by this question. By the way, finally, I got problem solved by following url
Facebook Redirect url in ruby on rails open ssl error
https://github.com/technoweenie/faraday/wiki/Setting-up-SSL-certificates
The RVM website suggests running rvm osx-ssl-certs update all
RVM Website: How to fix broken certificates in your operating system.
For Windows 7: the above solution link of Neil Hoff (Fix for Windows: https://gist.github.com/867550) did not work for me.
Here is what works:
Using cmd.exe:
curl -o c:\cacert.pem http://curl.haxx.se/ca/cacert.pem
set SSL_CERT_FILE=c:\cacert.pem
using msysgit bash:
curl -o /c/cacert.pem http://curl.haxx.se/ca/cacert.pem
export SSL_CERT_FILE=/c/cacert.pem
If you do not have curl on your windows 7 command line get it here:
http://www.confusedbycode.com/curl/#downloads
original solution is from here - credit to:
https://github.com/chef/chef-dk/issues/106
Dunn.
Andrei's answer worked for me, however I ran into a huge roadblock when trying to reinstall Ruby 1.9.3. Because I had installed a new version of Xcode since installing 1.9.3 I was unable to reinstall until I opened the Xcode Preferences and installed the Command Line Tools from the Downloads tab.
Check out certified gem. Description:
Ensure net/https uses OpenSSL::SSL::VERIFY_PEER to verify SSL
certificates and provides certificate bundle in case OpenSSL cannot
find one