Using UnixODBC and FreeTDS to connect to Pervasive SQL server in ubuntu? - freetds

I am trying to connect to a Pervasive Sql Server which is running on Windows 10 from an Ubuntu 14.04.4 server.
I am using the following services to try connect to the server:
FreeTDS
unixODBC
Before starting I tried to ping the host machine from the vm console with success.
I then run the following command to check FreeTDS has installed correctly;
tsql -C
Which returned:
Compile-time settings (established with the "configure" script)
Version: freetds v0.95.95
freetds.conf directory: /usr/local/etc
MS db-lib source compatibility: no
Sybase binary compatibility: no
Thread safety: yes
iconv library: yes
TDS version: 5.0
iODBC: no
unixodbc: yes
SSPI "trusted" logins: no
Kerberos: no
OpenSSL: no
GnuTLS: no
[freetds.conf] located in [/usr/local/etc] contains:
[PSQLServer]
host = **IP**
port = **PORT**
tds version = 8.0
[odbc.ini] located in [/usr/local/etc] contains:
[PSQLClient]
Description = Pervasive SQL Client Settings
Driver = FreeTDS
ServerName = PSQLServer
Database = **DBNAME**
Trace = No
UID = **USERNAME**
PWD = **PASSWORD**
TDS_Version = 8.0
[odbcinst.ini] located in [/usr/local/etc] contains:
[FreeTDS]
Description = FreeTDS unixODBC Driver
Driver = /usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so
Setup = /usr/lib/x86_64-linux-gnu/odbc/libtdsS.so
TDS_Version = 8.0
I tired using the tsql command adding [TDSVER=*] for each of the possible driver versions resulting in the same error message for each TDSVER.
*[5.0], *[6.0], *[7.0], *[7.1], *[7.2], *[7.3], *[7.4], *[8.0]
When testing the connection using the following command:
TDSVER=8.0 tsql -S PSQLClient -U **USERNAME** -P **PASSWORD**
Which returns the following errors:
Error 20012 (severity 2):
Server name not found in configuration files.
locale is "en_ZA.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
Error 20013 (severity 2):
Unknown host machine name.
There was a problem connecting to the server
After trying the above, I then tried to the isql command:
isql -v PSQLClient **USERNAME** **PASSWORD**
Which returns the following error messages:
[S1000][unixODBC][FreeTDS][SQL Server]Unable to connect to data source
[01000][unixODBC][FreeTDS][SQL Server]Unknown host machine name.
[ISQL]ERROR: Could not SQLConnect
Is it even possible to connect to [Pervasive SQL] via [node-odbc] and if so what am I doing wrong?
Any assistance would be greatly appreciated!

Most recent versions of Pervasive / Actian PSQL support Linux clients and have an ODBC driver for Linux. Since you're using Windows 10, you should probably be using PSQL v12. If you use v12, you can download the Linux client at http://www.pervasive.com/database/Home/Products/PSQLv12.aspx. There is an RPM and TAR available.

Related

Tiny_tds/freetds workaround needed for Heroku

Is there any way currently to install tiny_tds on a rails 7 app in Heroku on the latest stack? All the workarounds seem to be quite old / inoperable. I am trying to get an Azure MSSQL plugin up and running on Heroku.
I have been able to get the buildpack installed, but every time I use TDS (even making a connection via a heroku rails console), I get a timeout error. If I run the exact same command locally, it works.
client = TinyTds::Client.new host: '<host>.database.windows.net', database: "<database>",username: "<username>#<host>.database.windows.net",password: "<password>", port: 1433, azure: tr
ue, tds_version: 7.4, timeout: 300, login_timeout: 300
Adaptive Server connection timed out ([server].database.windows.net:1433)
Additionally, I can run the following successfully on a heroku bash prompt:
~ $ nslookup
> <host>.database.windows.net
Server: <server ip address>
Address: <server ip address>#53
Non-authoritative answer:
<host>.database.windows.net canonical name = <other host name>.eastus.database.windows.net.
<other host name>.eastus.database.windows.net canonical name = <other host name>.trafficmanager.net.
<other host name>.trafficmanager.net canonical name = <another host name>.control.database.windows.net.
Name: <another host name>.control.database.windows.net
Address: <ip address>
~ $ nc -zv <host>.database.windows.net 1433
Connection to <host>.database.windows.net (<ip address>) 1433 port [tcp/ms-sql-s] succeeded!
I have also tried using freetds on heroku (which is required for tinytds) and get timeouts, so I believe the error traces back to freetds' interaction with heroku or the heroku buildpack, of which I have tried a variety of versions (https://github.com/rails-sqlserver/heroku-buildpack-freetds):
On my local macbook, I can run the freetds tsql connection command to connect almost instantaneously to a variety of mssql databases (one on ec2 and two on azure), but the same command times out on heroku bash prompt:
~ $ tsql -H ***.rds.amazonaws.com -p 1433 -U *** -P ***
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
103Error 20002 (severity 9):
Adaptive Server connection failed
Error 20002 (severity 9):
Adaptive Server connection failed
There was a problem connecting to the server
FreeTDS version local and remote. I did no special "configuration" file settings other than setting the TDS_VERSION to 7.3 when installing the buildpack on heroku.
# LOCAL:
$ tsql -C
Compile-time settings (established with the "configure" script)
Version: freetds v1.3.13
freetds.conf directory: /opt/homebrew/etc
MS db-lib source compatibility: no
Sybase binary compatibility: yes
Thread safety: yes
iconv library: yes
TDS version: 7.3
iODBC: no
unixodbc: yes
SSPI "trusted" logins: no
Kerberos: yes
OpenSSL: yes
GnuTLS: no
MARS: yes
# Heroku:
$ heroku run bash -a <app>
Running bash on ⬢ <app>... up, run.4557 (Hobby)
~ $ tsql -C
Compile-time settings (established with the "configure" script)
Version: freetds v1.3.13
freetds.conf directory: /app/freetds/etc
MS db-lib source compatibility: no
Sybase binary compatibility: no
Thread safety: yes
iconv library: yes
TDS version: 7.3
iODBC: no
unixodbc: no
SSPI "trusted" logins: no
Kerberos: no
OpenSSL: yes
GnuTLS: no
MARS: yes
Any ideas would be greatly appreciated!
This was due to a TLS/openssl compatibility issue. Using gnutls fixes the issue for now.
Some other notes on the issue:
https://github.com/FreeTDS/freetds/issues/336
https://github.com/FreeTDS/freetds/issues/299
If you need to use freetds on heroku-22, see this pull request.
https://github.com/rails-sqlserver/heroku-buildpack-freetds/pull/20
Many thanks to #engineersmnky for some great questions that led to discovering this answer.

Try to connect to Informix database Cisco UCCX with unix ODBC - no success

Try to use Informix driver to connect over ODBC to Cisco UCCX database. Install IBM informix SDK
Files of SDK /opt/IBM/Informix_Client-SDK
odbcinst -j
unixODBC 2.3.9
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /home/alexniko/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8
odbc.ini
[ODBC Data Sources]
uccx
uccx2
[uccx]
DRIVER={IBM INFORMIX ODBC DRIVER (64-bit)}
UID=uccxhruser
PWD=TrebuSHet{}123
DATABASE=db_cra
HOST=uccx-01.fccps.local
SERVER=uccx_01_uccx
SERVICE=1504
PROTOCOL=onsoctcp
CLIENT_LOCALE=en_US.UTF8
DB_LOCALE=en_US.UTF8
[uccx2]
DRIVER={IBM INFORMIX ODBC DRIVER 2 (64-bit)}
UID=uccxhruser
PWD=TrebuShet{}123
DATABASE=db_cra
HOST=uccx-02.fccps.local
SERVER=uccx_02_uccx
SERVICE=1504
PROTOCOL=onsoctcp
CLIENT_LOCALE=en_US.UTF8
DB_LOCALE=en_US.UTF8
odbcinst.ini
[IBM INFORMIX ODBC DRIVER (64-bit)]
Driver=/opt/IBM/Informix_Client-SDK/lib/cli/iclis09b.so
Description=IBM INFORMIX ODBC DRIVER
UID=uccxhruser
PWD=TrebuShet{}123
DATABASE=db_cra
HOST=uccx-01.fccps.local
SERVER=uccx_01_uccx
SERVICE=1504
PROTOCOL=onsoctcp
CLIENT_LOCALE=en_US.UTF8
DB_LOCALE=en_US.UTF8
[IBM INFORMIX ODBC DRIVER 2 (64-bit)]
Driver=/opt/IBM/Informix_Client-SDK/lib/cli/iclis09b.so
Description=IBM INFORMIX ODBC DRIVER
UID=uccxhruser
PWD=TrebuShet{}123
DATABASE=db_cra
HOST=uccx-02.fccps.local
SERVER=uccx_02_uccx
SERVICE=1504
PROTOCOL=onsoctcp
CLIENT_LOCALE=en_US.UTF8
DB_LOCALE=en_US.UTF8
ldd -v /opt/IBM/Informix_Client-SDK/lib/cli/iclis09b.so
Have no error
Connecttion string in python:
SERVICE=1504;PROTOCOL=onsoctcp;
CLIENT_LOCALE=en_US.UTF8;DB_LOCALE=en_US.UTF8;
DRIVER=IBM INFORMIX ODBC DRIVER (64-bit);
UID=uccxhruser;PWD=TrebuShet{}123;
DATABASE=db_cra;
HOST=uccx-01.fccps.local;
SERVER=uccx_01_uccx;
when I try to connect receive error:
Can't open lib '/opt/IBM/Informix_Client-SDK/lib/cli/iclis09b.so' : file not found (0) (SQLDriverConnect)")
Trying to check driver work with isql -v uccx - receive error
[IM002][unixODBC][Driver Manager]Data source name not found and no default driver specified
[ISQL]ERROR: Could not SQLConnect
what am I doing wrong?

Ansible connection to docker engine on osx apple Silicon

I'm trying to connect to my local docker engine running on OSX (m1 chip) in order to create a dynamic inventory.
I've created a host file with the following config
I made sure that docker_containers module is well installed.
plugin: community.docker.docker_containers
docker_host: "unix://Users/ME/.docker/run/docker-cli-api.sock"
Then I run ansible-inventory --graph -i ./hosts/hosts-docker-local.yaml.
But I'm getting the following error:
[WARNING]: * Failed to parse /Users/ME/Projects/ansible-test/hosts/hosts-docker-local.yaml with auto plugin: inventory source '/Users/ME/Projects/ansible-test/hosts/hosts-docker-local.yaml' could not be
verified by inventory plugin 'community.docker.docker_containers'
[WARNING]: * Failed to parse /Users/ME/Projects/ansible-test/hosts/hosts-docker-local.yaml with yaml plugin: Plugin configuration YAML file, not YAML inventory
[WARNING]: * Failed to parse /Users/ME/Projects/ansible-test/hosts/hosts-docker-local.yaml with ini plugin: Invalid host pattern 'plugin:' supplied, ending in ':' is not allowed, this character is reserved to
provide a port.
[WARNING]: Unable to parse /Users/ME/Projects/ansible-test/hosts/hosts-docker-local.yaml as an inventory source
[WARNING]: No inventory was parsed, only implicit localhost is available
#all:
|--#ungrouped:
I tried
ansible-doc -t inventory -l | grep docker
community.docker.docker_containers Ansible dynamic inv...
community.docker.docker_machine Docker Machine inve...
community.docker.docker_swarm Ansible dynamic inv...
but somehow if I do this
ansible localhost -i ./hosts/hosts-docker-local.yaml -m community.docker.docker_containers
It complains
localhost | FAILED! => {
"msg": "The module community.docker.docker_containers was not found in configured module paths"
}
maybe something wrong with my module path, something wierd with OSX? (I installed Ansible with brew)
The inventory file must end in docker.yaml, as pointed out by #Zeitounator.
Uses a YAML configuration file that ends with docker.[yml|yaml].
https://docs.ansible.com/ansible/latest/collections/community/docker/docker_containers_inventory.html#synopsis

Ruby Sequel AS/400 connection issues

I need to connect to a AS/400 system using ODBC connection, and I'm using the Ruby sequel gem. My environment is just Ubuntu 14.04 running in virtual box. I'm able to run isql -v my.host.com and drop in to a sql console. When I try and do this from IRB, I get the error message.
require 'sequel'
db = Sequel.odbc(:drvconnect=>'driver={IBM i Access ODBC Driver};system=my.host.com;database=MYDBNAME;uid=MYUSERNAME;password=MYPASSWORD;DefaultLibraries=, *usrlibl;authentication=server')
tables = db[:QSYS2__SYSTABLES].where("TABLE_NAME like ?", "SYS%")
tables.each do |record|
puts record[:table_name]
end
#=> Sequel::DatabaseConnectionError: ODBC::Error: IM002 (0) [unixODBC][Driver Manager]Data source name not found, and no default driver specified
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/adapters/odbc.rb:21:in `drvconnect'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/adapters/odbc.rb:21:in `connect'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/connection_pool.rb:103:in `make_new'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/connection_pool/threaded.rb:224:in `make_new'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/connection_pool/threaded.rb:197:in `available'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/connection_pool/threaded.rb:133:in `_acquire'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/connection_pool/threaded.rb:147:in `block in acquire'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/connection_pool/threaded.rb:265:in `block in sync'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/connection_pool/threaded.rb:265:in `synchronize'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/connection_pool/threaded.rb:265:in `sync'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/connection_pool/threaded.rb:146:in `acquire'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/connection_pool/threaded.rb:104:in `hold'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/database/connecting.rb:251:in `synchronize'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/adapters/odbc.rb:44:in `execute'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/dataset/actions.rb:952:in `execute'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/adapters/odbc.rb:97:in `fetch_rows'
from /home/vagrant/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/sequel-4.32.0/lib/sequel/dataset/actions.rb:141:in `each'
I'm not familiar at all with AS/400 or using ODBC connections, but if isql works then maybe it's a user permission error?
Here is my /etc/odbc.ini
[my.host.com]
Description = IBM i Access ODBC Driver
Driver = IBM i Access ODBC Driver
System = my.host.com
UserID = MYUSERNAME
Password = MYPASSWORD
Naming = 1
DefaultLibraries = *usrlibl;
Database = MYDBNAME
I should also mention that the AS/400 system is located remotely at the my.host.com, so I'm not trying to connect to some local running service. I am able to ping the IP address of that host though.
Edit: I've changed my driver in the drvconnect to match what's in the odbc.ini as per the suggestion below. Also I should note that I have a /etc/odbcinst.ini file with the following
[IBM i Access ODBC Driver]
Description = IBM i Access for Linux ODBC Driver
Driver = /opt/ibm/iaccess/lib/libcwbodbc.so
Setup = /opt/ibm/iaccess/lib/libcwbodbcs.so
Driver64 = /opt/ibm/iaccess/lib64/libcwbodbc.so
Setup64 = /opt/ibm/iaccess/lib64/libcwbodbcs.so
Threading = 0
DontDLClose = 1
UsageCount = 1
[IBM i Access ODBC Driver 64-bit]
Description = IBM i Access for Linux 64-bit ODBC Driver
Driver = /opt/ibm/iaccess/lib64/libcwbodbc.so
Setup = /opt/ibm/iaccess/lib64/libcwbodbcs.so
Threading = 0
DontDLClose = 1
UsageCount = 1
You have this:
require 'sequel'
db = Sequel.odbc(:drvconnect=>'driver={iSeries Access ODBC Driver}; system=my.host.com;...
But then you show this:
[my.host.com]
Description = IBM i Access ODBC Driver
Driver = IBM i Access ODBC Driver
If you actually have the IBM i Access ODBC Driver, Then that's what you should reference in your code, rather than iSeries Access ODBC Driver.
Figured it out! It turns out that when you have your /etc/odbc.ini defined with all your connection info, you don't need a connection string.
require 'sequel'
db = Sequel.odbc(drvconnect: '')
tables = db[:QSYS2__SYSTABLES].where("TABLE_NAME like ?", "SYS%")
tables.each { |r| puts r[:table_name] }
This query takes a stupid long time to run on my machine, but it does return all tables that start with "SYS". The only change I did need to make to my /etc/odbc.ini for this to work was to rename the DSN to "default"
[default]
Description = IBM i Access ODBC Driver
Driver = IBM i Access ODBC Driver
System = my.host.com
UserID = MYUSERNAME
Password = MYPASSWORD
Naming = 1
DefaultLibraries = *usrlibl;
Database = MYDBNAME
Just for anyone else that may run into this issue, here are a few other things I did along the way to get things working. My setup is Ubuntu 14.04
Install unixodbc and unixodbc-dev
My my.host.com needed to be added to my /etc/hosts since it didn't resolve on public DNS.
The driver filename I installed is called ibm-iaccess-1.1.0.4-1.0.amd64.deb
running ldd /opt/ibm/iaccess/lib64/libcwbodbc.so showed that there was a missing symlink.`
Added missing symlink for /usr/lib/x86_64-linux-gnu/libodbcinst.so.1 to /usr/lib/x86_64-linux-gnu/libodbcinst.so.2
That's it. Hope that helps other people too.

MQTT:SSL routines:SSL3_GET_RECORD:wrong version number

I am trying to use SSL with MQTT and gets following error,
1379677998: Client connection from 127.0.0.1 failed: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number.
1379678058: OpenSSL Error: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure
1379678058: Socket read error on client (null), disconnecting.
My conf file has seetings as below,
port 8883
cafile /home/administrator/Downloads/mosquitto-1.2.1_dilip/test/ssl/test-root-ca.crt (also tried all-ca.crt here)
certfile /home/administrator/Downloads/mosquitto-1.2.1_dilip/test/ssl/server.crt
keyfile /home/administrator/Downloads/mosquitto-1.2.1_dilip/test/ssl/server.key
tls_version tlsv1
require_certificate true (tried commenting this too)
and I run, 08-ssl-connect-cert-auth.test from test folder. code snippet included below
mosquitto_tls_opts_set(mosq, 1, "tlsv1", NULL);
mosquitto_tls_set(mosq, "../ssl/test-root-ca.crt", "../ssl/certs", "../ssl/client.crt", "../ssl/client.key", NULL);
mosquitto_connect_callback_set(mosq, on_connect);
mosquitto_disconnect_callback_set(mosq, on_disconnect);
rc = mosquitto_connect(mosq, "localhost", 8883, 60);
Environment info:
Python 2.7.3
OpenSSL 1.0.1 14 Mar 2012
Description: Ubuntu 12.04.2 LTS
Release: 12.0
mosquitto-1.2.1/mosquitto-1.2
Please let me know what could go wrong here? I also tried generating certificates using gen.sh.
Thanks in advance.
-Dilip
On a general note - you should be generating your own certificates, don't use the ones provided by mosquitto for testing, or use the gen.sh script without modifying it for your own details.
To use the certificates provided, you should be using all-ca.crt in the broker. It contains the example root CA and intermediary CA certificates. The client only requires the root CA for verification purposes.
You are using a full path to the certificates in the broker configuration, but relative paths in the client. Are you sure that they are both correct?
Have you tried running the tests unmodified with make test? This would tell you if there is a problem with your openssl installation for example.

Resources