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.
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!
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…
If you haven’t attended CommunityOne conference then here is a sweat gift from Sun Video blog materialised in “Becoming a ZFS ninja” and “Developing in OpenSolaris: Solaris Device Drivers” presentations driven by Ben Rockwood and Max Bruning respectively. Enjoy.
Saw it a couple of days ago but recently this “confidential” information has leaked into public. Now it’s clear that so much anticipated and hyped Rock CPU is out of the game.
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.
Just as many other out there today I received a very promising poster from Oracle that stately confirms all our expectations and proves that SPARC and Solaris don’t droop.
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!
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:
# 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.
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:
- Stopped all processes that were using /var. In my case they were sendmail and named.
- Backed up the data.
# cd /var
# find . | cpio -o -Hnewc > /root/var.cpio
- I had to comment out /var in /etc/fstab because even in a single user mode I failed to unmount it.
- Rebooted into a single user mode.
- Created, mounted /dev/md3 and restored the data.
# 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
- And finally, updated /etc/mdadm.conf to reflect applied changes.
# mdadm --detail --scan > /etc/mdadm.conf