Posted on April 8th, 2014 No comments
Do you happen to find yourself in the situation that you have a program crash every now and then, but whenever this happens to you, you did not start the app in gdb?
Then I know that feeling; this guide will help you configure your test system to create a coredump whenever an app crashes, so if needed, you can use those at any later time to still create a backtrace. There are obviously some limitations, like stepping through and anything else funny you could do while debugging a running app. But it still does give you a good entry point.
NOTE: I do not advise to set this up on shared machines or critical machines. A coredump can contain sensitive data (memory extracts), which you would not want to be shared around.
With that cleared, it’s as simple as a few configuration steps:
Create any directory where you want to keep your coredumps. I use /cores
mkdir -m 777 /cores
This creates a world readable and writable directory
Configure your system to know WHERE to store the coredumps and how to name them. Create a file /etc/sysctl.d/99-coredump.conf, with the following content:
# I want to have core dumps in a world writable directory
kernel.core_pattern = /cores/%e-%t-%u.core
The pattern results in a filename /cores/NameOfBinary-TimeStamp-UserID.core; this helps yourself to identify the more recent crashes.
Modify the file /etc/security/limits.conf and add the line
* soft core unlimited
instructing the system to actually write coredumps for you.
Reboot your system and go ahead, make your apps crash. you will see files appear in /cores, if all is setup right.
You can at any time later start gdb with two parameters, first one pointing to the binary to debug, 2nd parameter to the corefile. Then normal gbd usage applies (if you miss debuginfo packages, you can even still install them at this time: the coredump remains valid). The usage of gdb goes beyond the scope of this article.
Posted on July 6th, 2010 8 comments
I’m in the unfortunate situation that my employer uses a Juniper SSL/VPN solution with network connect capabilities (to initiate a real tunnel).
The solution is built around some Java code, some suid services and obviously exists as 32bit only.
Since the update from v5 to v6.5, network connect does no longer work when initiated from the web interface, which is a shame. The issue is a 32bit library that seems no longer to be nicely wrapped and thus the 64bit java is no longer able to start the processes up. The worst about all of it: there is no error message, no log file.
If you’re lucky enough and you only have username / password auth, you can simply use ncsvc with some parameters. Of course I am less fortunate, and besides username/password, we also use a OTP RSA Token. And of course, ncsvc does not offer any option to enter a 2nd password.
so, no solution?
Let’s be more optimistic: there IS a solution, albeit a very hakish one. But I DO need to connect to our VPN, so I consider it a ‘valid’ workaround until this is hopefully really getting solved.
So, what needs to be done? When you initiate the VPN tunnel the first time from the web interface, you’re requested to enter the root password and the network_connect client is installed in ~/.juniper_network/network_connect and set suid. That’s about as far as you can get with the automatic stuff.
you’ll have to install gcc45-lib32 in order to be able to do the tasks at hand. But then you can convert the libncui.so to a binary which we can later on invoke directly.
# Change to the installed client folder
# Extract the LinuxApp java archive
# go to the actual binary client
# grab the certificate from the ssl/vpn gateway server
sh ../getx509certificate.sh <host.you.log.in.to> cert.der
# Convert the library into a binary
gcc -m32 -Wl,-rpath,$(pwd) -o ncui libncui.so
# chown and set the new binary suid
sudo chown root:root ncui
sudo chmod 6711 ncui
From now on we will be able to launch ncui (with some parameters) and have it initiate a tunnel for us. The needed command line for this is:
./ncui -h <host.you.log.in.to> -c DSID=<YourSessionID> -f cert.cer
So now the last obstacle: how to find your session ID? It’s stored in a cookie in your browser after logging in to the website. In Firefox you can get it from the properties/privacy or using various plugins (like Web Developer). The cookie name is DSID, so you should have an easy time finding it.
ncui weirdly asks for a password, but in my experience it never mattered what I enter, so I just press enter and go on. The application stays running and builds the tunnel. To tear it down, simply press CTRL-C and abort ncui.
Eventually you’re missing some more 32bit libraries, which I already had. use ldd against libncui and ncsvc to find out what other libraries you might be missing and install the corresponding 32bit equivalents.