Python: apply method or function in string format to a string

StackOverflow came in very handy for this: http://stackoverflow.com/questions/3061/calling-a-function-from-a-string-with-the-functions-name-in-python

If you wish to apply a method or function call that is currently in string format (e.g., you got an option with optparse) and wish to apply that method or function to another string, use getattr.

getattr(your_string, method_you_want_to_apply)()

The parentheses at the end apply the function or method rather than merely trying to obtain the attribute. 

Check for Kerberos ticket or authentication

Some commands require a valid Kerberos ticket, but if you want to integrate a check for a ticket yourself, try this:

/usr/kerberos/bin/klist -5 -c -s 2

Swap keys and values in a Python dictionary

Many options exist to swap or exchange keys and values in a Python dict() object (dictionary). Prior to creating a new dictionary of (value, key) pairs, it's worthwhile to check that


len( set( d.values() ) ) == len( d.values() )

Anyway, options: 

1. pairs = zip(d.values(), d.keys())
2. pairs = zip(d.itervalues(), d.iterkeys())
3. pairs = [(v, k) for (k, v) in d.iteritems()]

And to create a dictionary, just throw dict() around the zip() or list brackets. 

Source: http://docs.python.org/library/stdtypes.html#dict.items

"ERROR 2006 (HY000) at line 43: MySQL server has gone away" when importing MySQL dump

Having created a nice 1.6MiB SQL dump using Python, I ran into this nifty little error when importing it into MySQL 5.5:


ERROR 2006 (HY000) at line 43: MySQL server has gone away


Line 43 was where my giant INSERT was. Googling didn't help much. Importing a mysqldump-exported dump file worked fine, so after manually importing my data, I took a look at my Python-generated dump:

# wc asdf.sql
56 103353 2158554 asdf.sql

Versus the official MySQL dump: 


# wc sql/rhel_errata_2012-06-24.sql
57 213 2025975 sql/rhel_errata_2012-06-24.sql

Line 44 in the MySQL-generated dump was the extra line. It was another INSERT statement. The bulk_insert_buffer_size was way larger than my file, so what was wrong? 

mysql> SHOW VARIABLES LIKE 'bulk_insert_buffer_size';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| bulk_insert_buffer_size | 8388608 |
+-------------------------+---------+
1 row in set (0.00 sec)

Googling for (no quotes) "mysql maximum values in insert" (https://www.google.com/search?&q=mysql+maximum+values+in+insert) pointed me to the max_allowed_packet variable: 

# mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

+--------------------+---------+
|Variable_name       | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+

1048576 bytes is exactly 1MiB, so raising it to something larger than intended dump file size suffices: 

# mysql -e "SET GLOBAL max_allowed_packet = 8388608;"
# mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"
+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 8388608 |
+--------------------+---------+

Don't forget to add it to /etc/my.cnf for persistence.

Show Linux or *nix permissions in octal

Like many others before me, I briefly Googled for "ls show octal permissions" (without quotes) and got next to nothing immediately useful: https://www.google.com/search?q=ls+show+octal+permissions

I would've written the solution to this thread since I got this idea from there, but unfortunately, it's closed: http://www.unix.com/unix-dummies-questions-answers/119538-ls-switch-view-octal-permissions.html

Solution: ditch ls and use stat instead---stat can format its output similar to date.

$ stat -c %a "${filename}"
644

Removed LUN and multipath reports "tur checker reports path is down"

When removing a LUN from a Red Hat Enterprise Linux 5 (RHEL 5) server, I ran into this interesting issue:

[root@server ~]# multipath -ll
sdat: checker msg is "tur checker reports path is down"
sdbt: checker msg is "tur checker reports path is down"
sdct: checker msg is "tur checker reports path is down"
sdt: checker msg is "tur checker reports path is down"

This is annoying and problematic since running pvs or something similar will cause the system to hang as it tries to access the missing LUN. It's briefly covered below, but see also the official documentation: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/removing_devices.html

1. Stop using the volume and umount
2. Remove it from software RAID or LVM volume group
3. Use multipath -l to get the block devices names (e.g., sda, sdb, etc.)
4. Use multipath -f mpathX
5. To flush outstanding I/O ("sync"), use blockdev –flushbufs device

6. Make sure applications and things are no longer referencing the device(s)
7. echo 1 > /sys/block/device-name/device/delete

multipathd -k results in ux_socket_connect error

On Red Hat Enterprise Linux 5 (RHEL 5), when trying to enter the multipathd shell using multipathd -k, I ran into the following error:

ux_socket_connect: No such file or directory

Because running multipath -ll generated the desired output I assumed (and we all know what assuming does!) and began Googling a solution... and it turned out multipathd was not actually running or even set to start on boot. Solution:

chkconfig multipathd on
service multipathd start
multipathd -k

Lesson learned.

Cron not working for normal user

Recently I ran into an interesting "issue" where a user's cron job wouldn't work and restarting the cron daemon did no good. Having checked the /etc/cron.allow and /etc/cron.deny files, I found nothing relevant, and so I Googled the error found in /var/log/messages:

Apr  9 12:31:01 server crond[8993]: Authentication token is no longer valid; new one required.

No password was necessary for this account, so to the system, it was a "locked" account, whereas to me, it was a service account.

[root@server ~]# grep username /etc/shadow
username:!!:13306:0:90:14:::

 Setting a password resolved this.