A passionate openSUSE user
RSS icon Home icon
  • Debug a crash after it happened – without knowing about it upfront

    Posted on April 8th, 2014 Dominique Leuenberger 1 comment

    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.

  • Juniper VPN on openSUSE x86_64

    Posted on July 6th, 2010 Dominique Leuenberger 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
    cd ~/.juniper_networks/
    # Extract the LinuxApp java archive
    unzip ncLinuxApp.jar
    # go to the actual binary client
    cd network_connect
    # 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.