Does anyone know a way of testing if an odbc entry on the odbc.ini file is configured correctly?
I would like to know if my linux server is able to connect to my SQL Server using an ODBC entry I configured.
If you are using unixODBC as the ODBC driver manager then just do:
isql -v mydsn myusername mypassword
The most common problem is that the default source build setup is set to /usr/local/etc, not /etc, so you (as me) may be look at a nice config file but unused.
To verify it, just run
# odbc_config --odbcinstini
/usr/local/etc/odbcinst.ini
A simple symbolic link solve it.
Another problem can be a missing library, that you can verify by running the ldd. ex:
# ldd /opt/microsoft/sqlncli/lib64/libsqlncli-11.0.so.1790.0 | grep "not found"
libodbcinst.so.1 => not found
In this case, I need to put the libodbcinst.so.1 in LD_LIBRARY_PATH or in any directory in use by /etc/ld.so.conf.
If you choose to put in ld directories, do not forget to run ldconfig as root after it to update ldd cache file.
Related
I downloaded the 64-bit redshift odbc .rpm file. I am installing the driver for Oracle OBIEE. So, I don't want to install it system wide.
I decompressed the .rpm file to /u01/app/oracle/product with: rpm2cpio AmazonRedshiftODBC-64-bit-1.4.20.1001-1.x86_64.rpm | cpio -idmv
I installed unixODBC.
I added the following to /etc/odbcinst.ini:
[RedshiftDriver]
Driver=/u01/app/oracle/product/redshiftodbc/lib/64/libamazonredshiftodbc64.so
I added the following to /etc/odbc.ini:
[redshift]
Driver=Driver=/u01/app/oracle/product/redshiftodbc/lib/64/libamazonredshiftodbc64.so
Description=redshift
Host=<my redshift endpoint hostname>
Port=5932
Database=<my db>
locale=en-US
I run: isql -v redshift <myuser> <mypass>
I get:
[IM002][unixODBC][Driver Manager]Data source name not found, and no default driver specified
[ISQL]ERROR: Could not SQLConnect
I also tried the 32 bit driver. I am operating as root. The path to the .so file is correct.
What am I missing?
Hah. Proofreading my post and see that I put:
Driver=Driver= in odbc.ini.
Problem solved.
Then I realized I used the wrong port. It’s supposed to be 5439.
And to top it off I realize I posted this on SO instead of server fault.
It’s been a long week.
Maybe the procedure will help someone else looking for AWS redshift driver info.
I have installed gprbuild, xmlada, and gnatcoll. I am now attempting to install gnatcoll_postgres. Which I have downladed from here: https://github.com/AdaCore/gnatcoll-db/
Within the Postgres folder is a Makefile, which I execute like so...
[parallels#localhost postgres]$ ls
gnatcoll_postgres.gpr gnatcoll-sql-postgres-gnade.ads
gnatcoll-sql-postgres.adb gnatcoll-sql-ranges.adb
gnatcoll-sql-postgres.ads gnatcoll-sql-ranges.ads
gnatcoll-sql-postgres-builder.adb Makefile
gnatcoll-sql-postgres-builder.ads postgres_support.c
gnatcoll-sql-postgres-gnade.adb README.md
[parallels#localhost postgres]$ make Makefile
which: no gnatls in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/parallels/.local/bin:/home/parallels/bin)
make: Nothing to be done for `Makefile'.
[parallels#localhost postgres]$
Would anybody please be able to tell me what this means...
which: no gnatls in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/parallels/.local/bin:/home/parallels/bin)
make: Nothing to be done for `Makefile'.
Any help would be greatly appreciated.
Please see the xmlada and gnatcoll in my project below, does this look like it's installed correctly? I'm presuming this isn't correct...
Thanks,
Lloyd
It means that your GNAT installation binaries aren’t on your PATH.
The README.txt from the adacore.com site says, in part,
To start using the tools in command-line mode, you will need to add
{install_prefix}/bin
to your PATH environment variable. Alternatively, you can simply launch
{install_prefix}/bin/gps
and GPS will automatically add itself to the PATH - it will also find the
cross compiler, if you have installed everything in the default locations.
Note that GPS will add this at the end of the PATH, meaning that it will find first any other GNAT installations that you have in your PATH.
I strongly suspect that you’ve been doing the latter, so that GPS adds itself (actually, of course, its own location) to the PATH, so that when it launches the compiler it finds the correct one.
When you run make from the terminal, the compiler isn’t on the PATH, so neither are gnatls, gprconfig, gprbuild and the rest of the GNAT tools.
What you need to do is to take the first choice from the README, and add /home/parallel/opt/GNAT/2019/bin to (the front of) your default PATH. How you do that depends on your shell.
You will find xmlada, gnatcoll already installed.
In Cassandra the official documentation (https://wiki.apache.org/cassandra/GettingStarted) it states, to start the service use
'bin/cassandra -f'
Then use
'bin/cqlsh'
to access. But to use cqlsh in this way I always have to go to the bin folder. What is the procedure to make it work such that I can type 'cqlsh' from anywhere in the console to access (not have to be in the bin folder of Cassandra setup) ?
(just like we access python directly from anywhere by just typing python3 in console )
To get this work work, you have to add your Cassandra bin directory to your $PATH.
From a terminal prompt, check the contents of your $PATH.
$ echo $PATH
On my Ubuntu VM, this is what I see:
/usr/local/apache-maven/apache-maven-3.1.1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/jvm/jdk1.7.0_45/bin
Since you mention Python3, I'll check the location of that on my system as well:
$ which python3
/usr/bin/python3
As you can see, Python3 is in my /usr/bin directory, and /usr/bin is in my $PATH, which is why simply typing python3 works for me (and you as well).
There are a few ways to get your Cassandra bin directory into your $PATH. There is some debate about which is the "correct" way to do accomplish this. So in lieu of telling you how I would do it, I will provide a link to a question on AskUbuntu that details something like 3 ways to add a directory into your $PATH: How to add a directory to my path?
Use cassandra -f in your root folder and then you should be able to use cqlsh anywhere you have cassandra installed
Please suggest a solution for solving this issue?? While giving the command:
sqlplus /nolog
the error that occurred:
sqlplus: error while loading shared libraries:
libsqlplus.so: cannot open shared object file: No such file or directory
The minimum configuration to properly run sqlplus from the shell is to set ORACLE_HOME and LD_LIBRARY_PATH. For ease of use, you might want to set the PATH accordingly too.
Assuming you have unzipped the required archives in /opt/oracle/instantclient_11_1:
$ export ORACLE_HOME=/opt/oracle/instantclient_11_1
$ export LD_LIBRARY_PATH="$ORACLE_HOME"
$ export PATH="$ORACLE_HOME:$PATH"
$ sqlplus
SQL*Plus: Release 11.1.0.7.0 - Production on Wed Dec 31 14:06:06 2014
...
sudo sh -c "echo /usr/lib/oracle/12.2/client64/lib > /etc/ld.so.conf.d/oracle-instantclient.conf";sudo ldconfig
from https://help.ubuntu.com/community/Oracle%20Instant%20Client
I did solve this error by setting
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib:$ORACLE_HOME
yes, not only $ORACLE_HOME/lib but $ORACLE_HOME too.
You should already have all needed variables in /etc/profile.d/oracle.sh. Make sure you source it:
$ source /etc/profile.d/oracle.sh
The file's content looks like:
ORACLE_HOME=/usr/lib/oracle/11.2/client64
PATH=$ORACLE_HOME/bin:$PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib
export ORACLE_HOME
export LD_LIBRARY_PATH
export PATH
If you don't have it, create it and source it.
I know it's an old thread, but I got into this once again with Oracle 12c and LD_LIBRARY_PATH has been set correctly.
I have used strace to see what exactly it was looking for and why it failed:
strace sqlplus /nolog
sqlplus tries to load this lib from different dirs, some didn't exist in my install. Then it tried the one I already had on my LD_LIBRARY_PATH:
open("/oracle/product/12.1.0/db_1/lib/libsqlplus.so", O_RDONLY) = -1
EACCES (Permission denied)
So in my case the lib had 740 permissions, and since my user wasn't an owner or didn't have oracle group assigned I couldn't read it. So simple chmod +r helped.
On Ubuntu Server 20.04 and using instant client version 19.10.0.0, I used alien to install the rpm package. I got this error when I just used the -i option. However when, I added -c I did not have this issue. from the man page for alien:
-c, --scripts
Try to convert the scripts that are meant to be run when the package is installed and removed. Use this with caution,
because these scripts might be designed to work on a system unlike
your own, and could cause problems. It is recommended that you
examine the scripts by hand and check to see what they do before using
this option.
So it seems the correct configuration (in 19c) or the environment variables (in earlier versions) are set in these scripts which are not generated unless you run alien like this. (Thanks #Christopher Jones for correcting me on this)
sudo alien -i -c BasicPackage.rpm
sudo alien -i -c SqlPlus.rpm
PERMISSIONS:
I want to stress the importance of permissions for "sqlplus".
For any "Other" UNIX user other than the Owner/Group to be able to run sqlplus and access an ORACLE database , read/execute permissions are required (rx) for these 4 directories :
$ORACLE_HOME/bin , $ORACLE_HOME/lib, $ORACLE_HOME/oracore, $ORACLE_HOME/sqlplus
Environment. Set those properly:
A. ORACLE_HOME
(example: ORACLE_HOME=/u01/app/oranpgm/product/12.1.0/PRMNRDEV/)
B. LD_LIBRARY_PATH
(example: ORACLE_HOME=/u01/app/oranpgm/product/12.1.0/PRMNRDEV/lib)
C. ORACLE_SID
D. PATH
export PATH="$ORACLE_HOME/bin:$PATH"
You can try usage:
# echo "/usr/lib/oracle/12.2/client64/lib" > /etc/ld.so.conf.d/oracle.conf
# ldconfig
This problem are because oracleinstant client not configure shared library.
Could you please check if LD_LIBRARY_PATH points to the oracle libs
Don't forget
apt-get install libaio1 libaio-dev
or
yum install libaio
On Oracle's own Linux (Version 7.7, PRETTY_NAME="Oracle Linux Server 7.7"
in /etc/os-release), if you installed the 18.3 client libraries with
sudo yum install oracle-instantclient18.3-basic.x86_64
sudo yum install oracle-instantclient18.3-sqlplus.x86_64
then you need to put the following in your .bash_profile:
export ORACLE_HOME=/usr/lib/oracle/18.3/client64
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib:$ORACLE_HOME
in order to be able to invoke the SQLPlus client, which, incidentally, is called sqlplus64 on this platform.
This worked for me: sudo dnf install libnsl
It means you didn't set ORACLE_HOME and ORACLE_SID variables. Kindly set proper working $ORACLE_HOME and $ORACLE_SID and after that execute sqlplus /nolog command. It will be working.
#laryx-decidua: I think you are only seeing the 18.x instant client releases that are in the ol7_oci_included repo. The 19.x instant client RPMs, at the moment, are only in the ol7_oracle_instantclient repo. Easiest way to access that repo is:
yum install oracle-release-el7
I want to check in a script if PostgreSQL is installed or not on Linux and print the result.
Any suggestions on how to do the check?
What about trying the which command?
If you were to run which psql and Postgres is not installed there appears to be no output. You just get the terminal prompt ready to accept another command:
> which psql
>
But if Postgres is installed you'll get a response with the path to the location of the Postgres install:
> which psql
/opt/boxen/homebrew/bin/psql
Looking at man which there also appears to be an option that could help you out:
-s No output, just return 0 if any of the executables are found, or
1 if none are found.
So it seems like as long as whatever scripting language you're using can can execute a terminal command you could send which -s psql and use the return value to determine if Postgres is installed. From there you can print that result however you like.
I do have postgres installed on my machine so I run the following
> which -s psql
> echo $?
0
which tells me that the command returned 0, indicating that the Postgres executable was found on my machine.
Here's the information about using echo $?
We can simply write:
psql --version
output show like:
psql (PostgreSQL) 11.5 (Ubuntu 11.5-1.pgdg18.04+1)
If it is debian based.
aptitude show postgresql | grep State
But I guess you can just try to launch it with some flag like --version, that simply prints some info and exits.
Updated using "service postgres status". Try:
service postgres status
if [ "$?" -gt "0" ]; then
echo "Not installed".
else
echo "Intalled"
fi
There is no single simple way to do it, because PostgreSQL might be installed and set up in many different ways:
Installed from source in a user home directory
Installed from source into /opt or /usr/local, manually started or started by an init script
Installed from distributor rpm / deb packages and started via init script
Installed from 3rd party rpm / deb packages and started via init script
Installed from packages but not set to start
Client installed, connecting to a server on a different computer
Installed and running but not on the default PATH or default port
You can't rely on psql being on the PATH. You can't rely on there being only one psql on the system (multiple versions might be installed in different ways). You can't do it based on port, as there's no guarantee it's on port 5432, or that there aren't multiple versions.
Prompt the user and ask them.
There is no straightforward way to do this. All you can do is check with the package manager (rpm, dpkg) or probe some likely locations for the files you want. Or you could try to connect to a likely port (5432) and see if you get a PostgreSQL protocol response. But none of this is going to be very robust. You might want to review your requirements.
If you are running Debian Linux (or derivative) and if you have a postive return with > which psql, then simply type psql -V (capital "V") and you will get a return like: psql (PostgreSQL) 9.4.8
And if everything else fails from these great choice of answers, you can always use "find" like this. Or you may need to use sudo
If you are root, just type $$> find / -name 'postgres'
If you are a user, you will need sudo priv's to run it through all the directories
I run it this way, from the / base to find the whole path that the element is found in. This will return any files or directories with the "postgres" in it.
You could do the same thing looking for the pg_hba.conf or postgresql.conf files also.
For many years I used the command:
ps aux | grep postgres
On one hand it is useful (for any process) and gives useful info (but from process POV). But on the other hand it is for checking if the server you know, you already installed is running.
At some point I found this tutorial, where the usage of the locate command is shown. It looks like this command is much more to the point for this case.
aptitude show postgresql | grep Version worked for me
Go to bin directory of postgres db such as /opt/postgresql/bin & run below command :
[...bin]# ./psql --version
psql (PostgreSQL) 9.0.4
Here you go . .
You may also check in /opt mount in following path /opt/PostgresPlus/9.5AS/bin/
Well, all answersabove are good but not in all cases.
Basically check the folder /etc/postgresql/
in most cases there will be one subfolder eg. /etc/postgresql/11/ (or /etc/postgresql/12) which means that you have installed 11 (or 12) version, however in many cases you may have many of such subfolders, so having them all means that all those versions had been ever installed and could be in use ... so be aware of this important trace.
ps using Ubuntu 18.04