How to determine which yum package to install

If you have a library that's missing and can't quite figure out what provides the file, you can ask yum:

yum whatprovides '*/libz.so.1"

32 bit compatability

If you don't install rpms a lot, you get a little rusty. If you have a 32 bit program on your 64 bit server (or vice versa) you will know it when you get an error like this:

/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

If you link to the wrong version. Say you're file is linked to a 64 bit version at compile time and you alter the LD_LIBRARY_PATH (thinking you're going to fix it,) you will resolve the link, but since its not the right version you will get:

wrong ELF class:

To install the 32 bit compatibility, you should install the .i686 version e.g.

yum install -y libz.i686

You can also add the compatibility while you're at it:

 yum groupinstall "Compatibility libraries"

How to get a core dump

If your process is segfaulting, and you aren't getting a core dump, you need to make sure the kernel will allow them. First make sure that ulimit allows core files. 

$> ulimit -a 
core file size          (blocks, -c) 0

That says that core files are not allowed. You can set that for the current session by running:

$> ulimit -c unlimited 

Though you may be better off updating editing /etc/security/limits.conf. The next thing to set is fs.suid_dumpable and kernel.core_pattern. see: http://man7.org/linux/man-pages/man5/core.5.html


$> sysctl -w fs.suid_dumpable=2
$> sysctl -w kernel.core_pattern=/tmp/core

When setting the core_pattern, make sure that directory, in this case /tmp, is writable by the user process you want a core dump from. Be careful that your start script is not overriding anything anything. I found that /etc/init.d/functions daemon function set's the -c option and you need to export DAEMON_COREFILE_LIMIT=unlimited in your start script.

Once you have a core file, you can analyze with gdb e.g. 

$> gdb /tmp/core.0231
$> bt

The backtrace may require you to install debug symbols with debug-info. To do that I had to run:

$> yum install yum-utils

Then I could run debuginfo-install e.g. 

$> debuginfo-install httpd-2.2.15-30.el6.centos.x86_64

How to generate analyze statements for Oracle

Sometimes you get stuck with DBAs that can't be bothered to analyze your tables or indexes. There is an easy way to generate your own analyze statements. This example is assuming you're using sqlplus. Remove <TABLE_OWNER> with you're own table owner.

set pagesize 0
set linesize 255
spool /tmp/analyze-table.sql

select 'analyze table <TABLE_OWNER>.' || object_name || ' compute statistics;' from all_objects where owner like '<TABLE_OWNER>%' and object_type = 'TABLE';
exit

You will now have all the statements you need in /tmp/analyze-table.sql

How to extract files from an RPM

rpm2cpio <rpm-filename> |cpio -idmv

Simple encryption/description

I started using openssl and my public/private keypair to do some basic
password encryption deciption for use with expect to test production
servers. I found myself first using expect and hard coding my password and then
when I shared the script with someone I start freaking out wondering if
I shared my password by accident. This solves things.

Encrypt your password using your public key and put it as a binary file
somewhere safe like ~/.ssh/.encpass - you have access to decrypt it and
you probably have your public/private key pairs there, but you are not
likely to send that off when you share your cool bash/expect script.
In your bash script, you can simply run the decrypt function:

pass=$(openssl rsautl -decrypt -inkey ~/.ssh/id_rsa.pem -in ~/.ssh/.encpass)

Now pass has whatever you encrypted and you can use it in your script.
Here's what you do to pull this off. First, create a pem file of your
public private key pair and then encrypt your password. Steps:

> cd ~/.ssh
> openssl rsa -in id_rsa -outform pem > id_rsa.pem
> openssl rsa -in id_rsa -pubout -outform pem > id_rsa.pub.pem
> echo "my safe password" > .secret
> openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in .secret -out .encpass
> rm -f .secret

That's it. No need to keep the raw password around, just the encrypted
value. There's other variants you could do, you could create the .encpass
when you need and delete it after, whatever your comfortable with.

Unmarshaling JSON using Go

I had a Doh! moment today writing some code to Unmarshal JSON string into a Go object. I swore up and down I had the code right, but my Object just didn't get populated. I was searching around and was about to break down and post to ask for help when it finally clicked.

I used lower case names for the fields in my structure, effectively rendering them private! So, once I went through and made the fields all start with a Capital, making them public, I was able to populate the structure.

For example:

type Some struct {
  name string `json:"Name of item"`
  age int `json:"age"`
}

Is a valid structure, but you won't populate using

some := Some{}
data, err = json.UnMarshal(jsonBytes, &some)

If you check some.name - it will be empty because it's lower case. The correct struct is:

type Some struct {
  Name string `json:"Name of item"`
  Age int `json:"age"`
}