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.
SPARC/Solaris is still afloat
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.
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!
In: Linux, Veritas · Tagged with: Linux, mkinitrd, VxVM
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.
In: Linux · Tagged with: cron, pam
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:
- Stopped all processes that were using /var. In my case they were sendmail and named.
- Backed up the data.
- 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.
- And finally, updated /etc/mdadm.conf to reflect applied changes.
- Rebooted.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
# cd /var # find . | cpio -o -Hnewc > /root/var.cpio
# 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
# mdadm --detail --scan > /etc/mdadm.conf
First day at kindergarten
Yes, today is the first of September and it’s the first day when my boy went to a kindergarten. Ooh, time runs really fast indeed!
Mac OS X 10.6 Snow Leopard: the Ars Technica review
An outstanding and in depth review of freshly released Snow Leopard is available at Ars Technica. So if you’re wondering about the changes introduced with this update then the article is a must-read.
Back on the track
Since all good things alway come to the end, I’m sitting at the office re-spinning again and again vivid memories of the holidays I had. I doubt I’d be able to put my feelings and impressions into coherent words so I won’t even try just believe me – it was spectacular and flamboyant in every single way. I’m happy and fully refreshed though didn’t have much time to take a physical rest lying in a vegetative state on a beach. To be honest, I always disliked such sort of time spending and considered it as a perpetration. I’m once again convinced that “fly and drive” is my the most favorite and congenial way of spending holidays. But because I live in a dismal city I understand that my kid lacks the sun and the sea thus this time it was 60% of pool/sea games and 40% of hanging around/sightseeing. So here a few pics from Rovinj, Porec, Pula and, of course, Plitvice lakes…
Two weeks of silence
I doubt that anyone out there would notice my absence but, anyway, just for a record, tomorrow I’m ducking out to Croatia for vocations. Have fun and enjoy your time, friends!
Redsnow is waiting for reboot
I always used either pawnage or quickpwn tools to unlock/jailbreak my iPhone but yesterday I gave a go to another tool from the iPhobe Dev-Team called RedSnow which provides similar functionality to quickpwn. Said and done, I installed required package, upgraded my phone to 3.0.1 release and fired up the redsnow thoroughly following the instructions. I happily entered DFU when redsnow got stalled saying “Waiting for reboot”. From my previous experience I knew that it’s not a very bright idea to interrupt the process in the middle but after waiting for 20 minutes I had enough and boldly unplugged the phone from the usb port. Since there was no magical smoke coming out of the phone I sticked it back and by a miracle redsnow got awakened and continued its job. At first I took it as a coincidence so when the unlocking/jailbreaking was over and I decided to give it another spin by repeating the previous steps with one single exception – not to wait a second but disconnect the phone as soon as redsnow starts waving with “Waiting for reboot” message. And it worked out again with no glitches! So if you’ve been gazing at “Waiting for reboot” for half of the day just unplug and plug your iphone back into usb. The ending crowns the work!
In: Apple · Tagged with: iphone, redsnow