My test program works fine. I can create a client and a server and run them against each other. I can set my KRB5_CONFIG environment variable and use a local configuration for testing.
For some reason when I place the code in our production software it fails. Even if I strip our main() function to just calling gss_import_name() with a hard coded name I end up with the message "Cannot open configuration file".
If I run truss then I see a lot of Oracle going on. It tries to open lots of different Oracle trace files. It also tries to open
/krb5/krb.conf
instead of the file I specify.
It's as if Oracle is giving us the wrong gss, or maybe some other option in our huge and complex build system. I note -L/usr/lib/sparcv9 though this is after my -lgss now if that matters (too long since I worked in C on a regular basis!). The libgss.so.1 in that directory is larger than the one in /usr/lib - though putting that option into my test program's link command does not break it.
Any help?
Thanks
- Richard
This fixed what appeared to be a similar problem for us:
export KRB5_CONFIG=/etc/krb5.conf
It does appear likely that Oracle sets this env var incorrectly if it's not already set.
$ grep -r KRB5_CONFIG $ORACLE_HOME
Binary file /usr/lib/oracle/11.1.0.1/client64/lib/libclntsh.so matches
Binary file /usr/lib/oracle/11.1.0.1/client64/lib/libclntsh.so.11.1 matches
$ grep -r '/krb5/krb.conf' $ORACLE_HOME
Binary file /usr/lib/oracle/11.1.0.1/client64/lib/libclntsh.so matches
Binary file /usr/lib/oracle/11.1.0.1/client64/lib/libclntsh.so.11.1 matches
I found that the Oracle libraries contained an implementation of GSS. To make my code work I ensured I linked "-lgss" before linking any of the Oracle libraries.
I've not tested to see if this upsets Oracle in single sign-on, because we use Oracle with user name and password. That works fine.
I ran in to the very same issue with Oracle 11.2.0.4.0 on HP-UX 11.31 and wasted almost an entire day for that. Indeed, the crappy Oracle lib peforms a putenv with /opt/krb5/krb.conf and the tip from Richard Corfield makes the app even crash. The only workaround is to create a symbolic link. I have created a service request with Oracle for that issue.
Update (2014-06-02): I have received an update from Oracle. They confirmed the bug. It seems like there is a private GSS-API which is redefining symbols.
Bug 10184681 - ORACLE NEEDS TO USE VERSIONED SYMBOLS TO AVOID EXTERNAL SYMBOL CONFLICTS
This issue has been open since 2010-10. Terrible.
Related
I am trying to open an MS Access database in Base using the instructions here . (I've tried both .mdb and .accdb)
I can follow the process described by Gord with no problems until the last step, where it asks me to save the database in LibreOffice format. I choose a filename (say mylinuxdb.odb), click OK, and then Base opens with this error:
The connection to the data source "mylinuxdb" could not be established.
org/apache/commons/logging/LogFactory
Note that it is complaining about the new .odb database, not the MS Access database. Nonetheless, no data is imported.
Can anyone help with this?
Thank you.
Revised answer:
It appears that this issue is specific to distributions like Linux Mint that install LibreOffice Base by default. Presumably in order to enable embedded HSQLDB databases they also install a rather old version of HSQLDB which conflicts with UCanAccess. To fix that, remove LibreOffice's copy of HSQLDB. For Linux Mint that would be
sudo apt remove libhsqldb1.8.0-java
(original answer)
I was able to reproduce your issue with LibreOffice 6.4.6.2 on Xubuntu 20.04. It looks like the setup instructions on Ask Ubuntu may need to be tweaked.
In the meantime try opening your .odb file, clicking through any errors. When Base opens, choose
Edit > Database > Properties …
and notice that the "Database URL" text box has "jdbc:" in front of it.
so if the textbox contains
jdbc:ucanaccess:///home/gord/Documents/Database1.accdb
then apparently Base will try to use
jdbc:jdbc:ucanaccess:///home/gord/Documents/Database1.accdb
and that won't work. We need to have just
ucanaccess:///home/gord/Documents/Database1.accdb
in the text box (as in the screenshot above).
This is NOT (as per chosen answer) "specific to distributions like Linux Mint that install LibreOffice Base by default". Such statements should be avoided as they are clearly very difficult to prove except with rigorous analysis of all other situations, which is clear was not done and in practical terms cannot be done.
I just encountered this message with an LO Base form which uses a MariaDB installation on Windows 10, using a JDBC connection with the mysql-connector-java-8.0.28.jar connector .jar. The form was created only minutes previously.
Interestingly, I happened to have a Python application running at the same time but, and I stress, this Python application does not use any kind of connection to any mysql database whatsoever. Nor, being CPython, does it use Java in any way whatsoever.
I find that when I close the Python application I am then able to open the LO Base form. Furthermore, after having first opened the LO Base form I am then able to run the Python application.
As to why this ludicrous error should arise in these circumstances in the first place, I do not yet know. Chalk it down to yet one more LO anomaly and oddity around which you have to navigate by hook or by crook.
There is an application on remote machine with Linux OS(Fedora), writing to the log file when certain events occur. Some time ago I changed format of the message being written to the log file. But recently it turned out that for some reason in some seldom cases log files with old format messages appear there. I know for sure that none part of my code can write such strings. Also there is no instance of the old application running. Does anyone have some ideas why it can happen? It's not possible to check which process writes those files because anything like auditctl is not installed there, and neither package manager or yum to get it or install. Application is written in C language.
you can use fuser command to find out all the processes that are using that file
`fuser file.log`
Would like to ask for advice.
there is a need for binary to have a mechanism for self update. Lets imagine binary rolls on host A and updates-server is server B.
Lobster method is to fork bash script with wget/ftp/ncftp/etc getter wich will download and replace. But ehm...there is no such tools on A and they will not be installed.
In short I can't use any external software tools(external to running binary).I can just hardcode mechanism in running binary.
As binary image runs it can load binary(and md5 file) simply via tcp sockets in tmp file,then do md5 compare and if everything ok then replace binary and restart itself. Its easy to do, but I have some strange feeling...dunno.
Mb someone can share and advice?:)Thank you in advance.
Conditions: binary is written in pure c. freebsd is binary rolling side and update-serve is centos. So java/python/c++/any is available at server side but not on free. Y, tobe honest its is possbile install some tools on client side and openfirewall for ftp, but want to avoid and hardcode :)
ADDED: must be noted that the enviroment between A and B is secured..eghm...as we think, in any way security and access problem and spoofing/sniffing out of our world there :) its just local update implementation mechanism for some binary which nowdays we update from center within expect scripts via ssh.
You will have to reimplement a whole host of functionality if you want to do so. My easiest suggestion would be to link to libcurl, hardcode the download path into your executable and write the image of your executable back to $ARGV[0]. However, you should definitely rethink your distribution concept, most distributions do some form of package management, and using it is the easiest alternative for all parties involved.
First of all check if you can modify a binary when a process is executing it, some system does not allow it.
You say you can not use external tool so probbly you can not create another "updater program" which will do the chenge instead of your binary.
Probalby you can download such program (from where you want to downlaod your update), execute it (exec, replaces current process with the new one)
that executed process will download and upded your main one, and then exec to it.
I've got a Windows minidump (C code) and a corresponding exe file. Unfortunately, I don't have the exact matching .pdb files, but I do have .pdbs that contain the exact same code just built at a different time. In Windbg, I can use:
.symopt+0x40
To tell it to load anything, even mismatched symbol files. This works great in this particular instance, and I'm able to get a proper call stack. I'm just curious as to whether or not Visual Studio has any such feature. We use pretty much every different version of VS here, so it doesn't matter which version it might be in. Thanks.
Try this utility:
ChkMatch utility can be used to check whether an executable and debug information file match. It can also be used to enforce matching between an executable and debug information file, if they are compatible.
For more information about debug information matching and related issues, see this article.
Supported debug information formats: DBG, PDB 2.0, PDB 7.0...
There is no override, but the poster to this question found a way to modify the PDB files to make them match the EXE.
Thanks to one of the comments on the
first answer, I checked out a link to
the pdfs of the book "Undocumented
Windows 2000 Secrets: A Programmers
Cookbook". And the author goes into
great detail about the pdb file
format. As I said before, I had
already loaded the pdb into a hex
editor and flipped some bits around
appearing that I made the
age/signature match, but it didn't
work. Well, after using the utility
from the W2k secrets book to "explode"
the pdb into the included streams, I
found out that they hide another
reference to the age in stream
3!!!!!!! Once I flipped that one as
well, it matched up in windbg.
Not sure if you want to go to this much trouble, but it looks like it can be done. If this is for production support then it could be worth your while.
Visual Studio and Windbg match pdbs by comparing the timestamps in the Executable header with timestamps store in the pdb file. You can view the timestamp by running dumpin /headers .
I haven't used chkmatch but modifying either the exe or pdb to match each other should work fine.
Be aware that this technique may not be enough to debug your binary. John Robbins in his book 'Debugging Windows' (which I can recommend) mentions that he's seen different build results from the identical source tree built at almost identical times.
Always build pdb symbols with your builds (including release builds) and archive them alongside the build products and include the .map file for good measure.
According to this post its possible to use sos windbg commands as well in visual studio. But i am not sure if ".symopt" also falls into this category.
I'm told that in VS2019 (16.7 .. 16.8 ballpark) that they switched to a multi-threaded PDB file generator to speed that up.
A side effect is that sections of the file, being generated on different threads, may end up in a different order in the file.
Bottom line, it is even more important than before that you use the PDB that was built with the EXE and no other.
There is a strange issue about sybase interfaces file. We have an application which is run on solaris sparc OS and this application uses open client (sybase OCS-12_5) for database operations. When we upgrade our database server to sybase 15.03, our application didn't work. then I start the research for figure out why it does not work. End of the my research, i found the the reason is sybase15.03's interfaces file. Somehow,15.03's interfaces file is damaged i think. But sybase 12.5 interfaces file and sybase 15.03 interfaces file is same.I checked interfaces file for unknown character or carrige return character but there is no any strange character in it. When I copied sybase12.5's interfaces file to sybase15 directory, application runs correctly. Is there anyone to explain this?
PS: Sybase libraries looks for $SYBASE env. variable and reads the $SYBASE/interfaces file for gather server information like server host and port
Thanks and regards.
Sounds like a minor error in the 15.0.3 interfaces file format.
Suggested approach to diagnosing:
(Unix) diff the working and non-working interfaces files - if the servers they describe is the same the difference should be apparent pretty quickly.
Check the format against the rules in Sybase documentation.
If the problem is still not manifest, then 'divide an conquer' might be the next step - try a smaller subset of the problem interfaces file.
Failing that, you could post equivalent entries from the two files here and see if the community can spot the problem.
Check for the space in between lines and make sure there is a extra empty line at the end of the interface file.
Another thing to make sure is the network setting you have choose. It should be the same. It would be most probably TCP. Some versions in 12.5 used to put other entries.
Another method to correct this is to use a DSCP method. This ensures that the interface file is correct.