Snow Leopard and madwimax

If you’re one of the Yota’s frustrated users, me is also included, because of lack support for Snow Leopard, then here is a possible solution, though being currently under development, that could possibly make you a bit happier and fill your soul with hope:

Note, that this solution is under development and there is no guarantee it will work for you but still it’s the only option we all have at the moment. As far as I know, the patches have been already sent to the upstream project (madwimax) so it’s expected to become more matured in the near future. For now, lets say “Thank you” to the guys who’ve made it possible: siglost, kesik and of course the initial author of madwimax Alexander Gordeev.

Keynote speech from Jeff Bonwick and Bill Moore

If you followed Kernel Conference Australia 2009, also mentioned in my blog here, you’d noticed that not every presentation was available for online visitors and that made me mirthless, since I was so much keen on listening about ZFS and its future, i.e. quota support, dedup, triple raidz, shadow migration, etc. from the creator’s lips. But no more brooding, for today this video was finally published at Sun’s Video Blog. Enjoy!

Oracle’s Exadata innuendo

During todays conference organized by Brocade and called “Brocade Extraordinary Networks 2009”, I couldn’t leave unnoticed a presentation made by Sun Microsystem’s Senior Systems Architect in CIS region Vitaly Soloviev about recently announced Exadata V2. Though I learnt nothing new, there was one thing that drew my attention so now I couldn’t get it out of my head – answering a question from the audience “if it’s doable to use another Exadata rack on the remote site and make the two highly available to tolerate the failures and does such built-in feature ever exist” Vitaly replied he wasn’t eligible to answer such questions and we just should be patient. Lets wait and see, what else Oracle keeps under its sleeve…

Oracle and Sun Live Event

Found an intriguing invitation from Oracle in my inbox which says:

You are invited to attend this exclusive live Webcast in which Oracle CEO Larry Ellison will unveil an innovative new product, the world’s first OLTP database machine with Sun FlashFire technology. Don’t miss this opportunity to learn firsthand how the partnership between Oracle and Sun can benefit your business now and in the future.

Who: Larry Ellison, CEO, Oracle, and John Fowler, EVP, Sun
When: Tuesday, September 15, 2009, 1 p.m. PT

If you’re interested you could register for this event here. While you’re signing in take a look at the Sun/Oracle logo depicted on a rack: Sun at the top and Oracle’s name in the bottom which sounds logical to me, especially if you look at it from Sun as a hardware and Oralce as a database perspective.

Do vxinitrd after kernel upgrade

Just a quick reminder. If you have your root disk on a Linux box encapsulated then don’t forget to recreate initrd image after the kernel has been updated.

/usr/lib/vxvm/bin/vxinitrd /boot/VxVM_initrd.img 'uname -r'

Otherwise you’ll end up being welcomed by the following message once you reboot.

Kernel panic - not syncing: Attempted to kill init!

Have a nice day!

Failed to open PAM security session

If one day you notice that your super-duper script doesn’t work when executed from cron and crond itself is whining about:

CRON (username) ERROR: failed to open PAM security session: Success
CRON (username) ERROR: cannot set security context

Then the most obvious step from here is to take a look at /etc/pam.d/crond and /var/log/secure (if you’re running Redhat based Linux distro):

#
# The PAM configuration file for the cron daemon
#
#
auth       sufficient pam_rootok.so
auth       required   pam_env.so
auth       include    system-auth
account    required   pam_access.so
account    include    system-auth
session    required   pam_loginuid.so
session    include    system-auth

In case if /var/log/secure has similar lines check your /etc/security/access.conf and make sure that cron is allowed for everyone or at least for the user experiencing the problem:

pam_access(crond:account): access denied for user `username’ from `cron’

Otherwise, a word “session” should give you a hint on a possible issue with system-auth section. Lets check it:

cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

The most critical module here is pam_unix.so which retrieves account information from /etc/passwd and /etc/shadow. Check them for the consistency because in my case /etc/shadow was a culprit missing a record for a username. Once it was fixed the errors had stopped popping up.

Migrating from RAID0 -> RAID1 with mdadm

Because of a stupid mistake made during a hectic installation of RHEL /var partition was configured as RAID0 instead of RAID1. Thankfully, it could be easily fixed though with a short downtime. Here is how I did it:

  1. Stopped all processes that were using /var. In my case they were sendmail and named.
  2. Backed up the data.
  3. # cd /var
    # find . | cpio -o -Hnewc > /root/var.cpio
  4. I had to comment out /var in /etc/fstab because even in a single user mode I failed to unmount it.
  5. Rebooted into a single user mode.
  6. Created, mounted /dev/md3 and restored the data.
  7. # mdadm --stop /dev/md3
    # mdadm --create --verbose /dev/md3 --level=1 --raid-devices=2 /dev/sdb2 /dev/sd2
    # mkfs.ext3 /dev/md3
    # mount /var
    # cd /var; cpio -i < /root/var.cpio
  8. And finally, updated /etc/mdadm.conf to reflect applied changes.
  9. # mdadm --detail --scan > /etc/mdadm.conf
  10. Rebooted.