I have two CentOS 6.7 machines (server A and B). Same package versions are installed on each system.
Last week I enabled the openSSH FIPS 140-2 module on Server A, and that system works flawlessly (including tsql queries to a SQL Server instance).
Today I went through the same steps on Server B (in the link above). After rebooting, fips showed enabled and tested OK - but tsql (to the same SQL Server instance) stopped working with the following error:
[serverB ~]# tsql -S egServer80 -U myusername
Password:
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
Error 20002 (severity 9):
Adaptive Server connection failed
There was a problem connecting to the server
I check the log files and find this:
tsql: Libgcrypt warning: MD5 used - FIPS mode inactivated
Enabling debug in freetds yielded this additional error:
14:56:46.617196 3577 (net.c:1366):'''handshake failed: GnuTLS internal error.
Backing out the FIPS module (removing fips=1 from grub.conf) and rebooting set things back and I was again able to tsql into my SQL Server instance.
Both CentOS machines use the same libgcrypt version (1.4.5).
Why (or how) is enabling FIPS in grub causing libgcrypt to fail on this one machine? Clearly something configuration is off between the machines, but I cannot spot it, and have exhausted resources in finding where to look next.
NOTE #1:
I can reproduce the tsql problem on Server B without enabling FIPS 140-2 in grub, by creating an empty file /etc/gcrypt/fips_enabled. Removing this file sets the system back to normal, and tsql works again.
NOTE #2:
Adding file /etc/gcrypt/fips_enabled on Server A does not affect tsql function at all.
Additional Information
libgcrypt version 1.4.5
freetds version 0.91
openssl version 1.0.1e
CentOS version 6.7
Related
I'm trying to follow the diesel.rs tutorial using PostgreSQL. When I get to the Diesel setup step, I get an "authentication method 10 not supported" error. How do I resolve it?
You have to upgrade the PostgreSQL client software (in this case, the libpq used by the Rust driver) to a later version that supports the scram-sha-256 authentication method introduced in PostgreSQL v10.
Downgrading password_encryption in PostgreSQL to md5, changing all the passwords and using the md5 authentication method is a possible, but bad alternative. It is more effort, and you get worse security and old, buggy software.
This isn't a Rust-specific question; the issue applies to any application connecting to a Postgres DB that doesn't support the scram-sha-256 authentication method. In my case it was a problem with the Perl application connecting to Postgres.
These steps are based on a post.
You need to have installed the latest Postgres client.
The client bin directory (SRC) is "C:\Program Files\PostgreSQL\13\bin" in this example. The target (TRG) directory is where my application binary is installed: "C:\Strawberry\c\bin". My application failed during an attempt to connect the Postgres DB with error "... authentication method 10 not supported ...".
set SRC=C:\Program Files\PostgreSQL\13\bin
set TRG=C:\Strawberry\c\bin
dir "%SRC%\libpq.dll" # to see the source DLL
dir "%TRG%\libpq__.dll" # to see the target DLL. Will be replaced from SRC
cp "%SRC%\libpq.dll" %TRG%\.
cd %TRG%
pexports libpq.dll > libpq.def
dlltool --dllname libpq.dll --def libpq.def --output-lib ..\lib\libpq.a
move "%TRG%"\libpq__.dll "%TRG%"\libpq__.dll_BUP # rename ORIGINAL name to BUP
move "%TRG%"\libpq.dll "%TRG%"\libpq__.dll # rename new DLL to ORIGINAL
At this point I was able successfully connect to Postgres from my Perl script.
The initial post shown above also suggested to copy other DLLs from source to the target:
libiconv-2.dll
libcrypto-1_1-x64.dll
libssl-1_1-x64.dll
libintl-8.dll
However, I was able to resolve my issue without copying these libraries.
Downgrading to PostgreSQL 12 helped
I am having problems with odbc psql link on centos8 and with postgres-odbc version 10.3(this one was the default one in the repository)
I have defined my ssl cert files as such
pqopt={sslrootcert=/etc/ssl/certs/db_ssl_cert/client.crt \
sslcert=/etc/ssl/certs/db_ssl_cert/postgresql_client.crt \
sslkey=/etc/ssl/certs/db_ssl_cert/postgresql_client.key}
But I keep getting error(when using isql), even though I can connect using psql
[08001][unixODBC]libpq connection parameter error:invalid connection option "{sslrootcert"
I get this error no matter what I put in front of the first = sign.
Should the certificates be in ~/.postgresql/ directory?
What is the problem? On my windows machine I input parameters as above and no problems with the driver version 11.0, should I simply update the driver to the latest version, or what would be the solution as pgopt was supported from 9.6 postgres-odbc?
I'm struggling with connecting to Impala which is part of a kerberised CDH cluster via JDBC driver. For authentication I need to acquire a Kerberos ticket on my machine. kinit works like a charm. The strange is that, when I setup KRB5CCNAME variable pointing to a file the file remains empty after successful authentication, but klist shows that I'm authenticated. Is it the expected behaviour?
The reason I ask this is that, my java app can't connect to Impala and the error message suggest that the empty file could be the problem. However, a python script can connect to the same Impala from the same machine.
It is a Mac 2018.
It shouldn't.
Apple has its own bundled kerberos implementation (Heimdal) which does this strange empty file thing.
I installed krb5 package from brew, modified the PATH accordingly and it works fine.
myself#mymachine:~$ brew info krb5
krb5: stable 1.16.2 (bottled) [keg-only]
Network authentication protocol
https://web.mit.edu/kerberos/
/usr/local/Cellar/krb5/1.16.2 (160 files, 3.7MB)
Poured from bottle on 2018-12-18 at 15:20:46
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/krb5.rb
==> Dependencies
Required: openssl ✔
==> Caveats
krb5 is keg-only, which means it was not symlinked into /usr/local,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.
If you need to have krb5 first in your PATH run:
echo 'export PATH="/usr/local/opt/krb5/bin:$PATH"' >> ~/.bash_profile
echo 'export PATH="/usr/local/opt/krb5/sbin:$PATH"' >> ~/.bash_profile
For compilers to find krb5 you may need to set:
export LDFLAGS="-L/usr/local/opt/krb5/lib"
export CPPFLAGS="-I/usr/local/opt/krb5/include"
For pkg-config to find krb5 you may need to set:
export PKG_CONFIG_PATH="/usr/local/opt/krb5/lib/pkgconfig"
==> Analytics
install: 198 (30 days), 614 (90 days), 1,986 (365 days)
install_on_request: 182 (30 days), 557 (90 days), 1,768 (365 days)
build_error: 0 (30 days)
myself#mymachine:~$ /usr/bin/klist --version
klist (Heimdal 1.5.1apple1)
Copyright 1995-2011 Kungliga Tekniska Högskolan
Send bug-reports to heimdal-bugs#h5l.org
Similar issue will arise on Windows, where Kerberos does not respect whether KRB5CCNAME environment variable is set or not. The solution for this is using older version. This page mentions 4.0.1 version, however on the Kerberos page you can find 4.1. The first will use file cache, the latter will use API and pretty difficult to ask it not to use it.
I'm using:
CentOS 6.7
Zend.1.2.15 using oci8, using instantclient 11.2 x64
PHP 5.4.45
Trying to connect to an Oracle:
Oracle Database 10g Release 10.2.0.4.0
Already checked credentials, already tried to connet to other Oracle server but the error still the same:
12546 ORA-12546: TNS:permission denied *
Already gave 0777 permission to /usr/local/oracle/11.2/client64/ following some answer around but none of them solved.
Server does not have the IP in any sort of blacklist.
The same code runs in any other Windows PC with OracleInstantClient and no further configuration was needed on the server about giving an IP permissions to access or any permission at all.
Is there something more that I can check to solve this?
After hours searching I found this article: http://www.emsperformance.net/2013/12/20/connecting-to-oracle-database-from-php-with-oci8/ which is by far the best article explaining the installation process of LAMP, Oracle, Zend.
The setting I was missing is:
setsebool -P httpd_can_network_connect on
Edit: After a while this answer still looks useful to someone, worths to say that this happens because the machine has SELinux activated, usually in the enforcing mode. I would not recommend to disable SELinux, but setting it to permissive looks to ease the process of identifying some problems with it. You can check SELinux status by sestatus.
A full list of booleans on SELinux is available at: https://wiki.centos.org/TipsAndTricks/SelinuxBooleans
Overall information: https://wiki.centos.org/HowTos/SELinux
I am using Perl 5.14.2 on Ubuntu wheezy 64 bit.
I am trying to connect to a Pervasive SQL server v9.5 that is installed on a windows 2008 machine.
I tested the connection with isql and it works properly, I tested with the following command:
isql -v <db_name>
I use the DBD:ODBC v1.39 (latest version) perl module installed from cpan.
I am using the following command to connect to sql server:
use DBI;
my $db = DBI->connect('dbi:ODBC:Moked');
Moked is the connection name that was defined in the unixodbc v2.2.14 in odbc.ini.
/etc/odbc.ini
[Moked]
Driver=PERVASIVE_ODBC
Description=Pervasive ODBC Interface: Moked
ServerName=<ip>:<port>
DBQ=MIDA
UID=
PWD=
OpenMode=0
PvTranslate=
when I try to connect with the command i showed above I get error SQL-HY001 that by googling I understood that it relates to memory allocation, usually people get these while querying and not while trying to connect/
it seems that DBI does recognize the connection because if I type a different name, for example 'Moked2', i get the error SQL-IM002 instead.
any ideas?
how can I debug this issue further?
any information regarding the issue would be greatly appreciated.
thanks!
You are getting the memory allocation error because the PSQL v11 client cannot reliably connect to a PSQL v9.5 server. If you want to use the v11 client, you need the v11 server too. You might be able to get away with the v11 client at a Btrieve level but there were significant changes between v9 and v11 on the ODBC side.