Categories
Shell script

Redirection in Shell-Unix/linux

Redirection is a function common to most command-line interpreters, including various unix shells that can redirect standard streams to user specified locations.

UNIX STANDARD I/O Streams

0- stdin (Standard input)

1- stdout (Standard output)

2- stderr (standard error)

 

 

 

Redirecting standard input and standard output

simple redirection to a file:  $command  > file

redirection &  appending to a file:   $command >> file

Redirecting to and from the standard file handles

eg: $ command  2> file

executes the command & redirects standard error to file.

Merging of standard error into standard output can be obtained by

eg: $ find / -name .profile > results 2>&1

 

Redirect to multiple outputs

The standard command “tee” can be used to redirect output from a command to several destinations

eg: $  ls -lrt | tee xyz

this redirects the file list output to both “standard output” and “file xyz”.

 

 

 

 

Categories
technews

HP Names Meg Whitman President and Chief Executive Officer

HP today announced that its board of directors has appointed Meg Whitman as president and chief executive officer.

In addition, Ray Lane has moved from non-executive chairman to executive chairman of the board of directors, and the board intends to appoint a lead independent director promptly. These leadership appointments are effective immediately and follow the decision that Léo Apotheker step down as president and chief executive officer and resign as a director of the company.

Categories
Linux

A quick overview of Linux kernel crash dump analysis

The Red Hat Crash Utility is a kernel-specific debugger. It is usually used for performing postmortem system analysis when the system panicked, locked up, or appears unresponsive. In this short article, Eugene Teo will give a quick overview of how you can install crash and how you can use it to get important information from the crash dump files for debugging and root-cause analysis purposes.

Prerequisites

The crash utility has the following three prerequisites:

  • Kernel object file: A vmlinux kernel object file. The vmlinux file associated with the running kernel is typically found in the /boot directory for Red Hat Enterprise Linux 3 and /usr/lib/debug/lib/modules/ directory for both Red Hat Enterprise Linux 4 and 5.
  • Kernel crash dump: This may consist of a kernel crash dump file generated from any of the three crash dump facilities (Diskdump, Netdump, or Kdump). The filename is called vmcore or vmcore.incomplete (if it is not generated completely), and is typically found in /var/crash/ by default. Diskdump will be discussed in the next section.
  • Linux kernel versions: The crash utility is backwards-compatible to at least Red Hat Linux 6.0, up to Red Hat Enterprise Linux 5.

Install crash

Starting with the Red Hat Enterprise Linux 3 release, the crash utility is automatically installed during the system installation if the Development Tools package set is selected. If the crash utility is not installed, download and install the binary RPM as follows:

# rpm -ivh crash-4.0-2.30.i386.rpm

Preparing…                ########################################### [100%]

1:crash                  ########################################### [100%]

The crash executable will be installed in the /usr/bin directory.

Also, before you can invoke crash on a vmcore, you need to install the associated kernel debuginfo package. The vmlinux kernel debug information is stored in a separate debuginfo file. The debuginfo package needs to match the kernel version, variant (like “smp” or “hugemem”) and architecture. You can download the packages at ftp://ftp.redhat.com/pub. See the comments in the following example:

# file ./vmcore <– will show you the kernel architecture

./vmcore: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from ‘vmlinux’

# strings vmcore | fgrep -m1 ‘Linux ‘ <– will show you the kernel variant

Linux version 2.6.9-22.EL (bhcompile@porky.build.redhat.com) (gcc version 3.4.4

20050721 (Red Hat 3.4.4-2)) #1 Mon Sep 19 18:20:28 EDT 2005

# rpm -qa kernel-debuginfo <– will show you all the versions installed

# rpm -ivh kernel-debuginfo-2.6.9-22.EL.i686.rpm

Preparing…                ########################################### [100%]

1:kernel-debuginfo       ########################################### [100%]

# ls /usr/lib/debug/lib/modules/ -l

total 24

drwxr-xr-x 3 root root 4096 May 2 10:41 2.6.9-22.EL

drwxr-xr-x 3 root root 4096 May 2 10:41 2.6.9-22.ELhugemem

drwxr-xr-x 3 root root 4096 May 2 10:41 2.6.9-22.ELsmp

# ls /usr/lib/debug/lib/modules/2.6.9-22.EL -l

total 32848

drwxr-xr-x 9 root root     4096 May 1 19:50 kernel

-rwxr-xr-x 1 root root 33583473 Sep 20 2005 vmlinux

Take note that:

  • You should use -ivh rather than -Uvh when installing the kernel package. This will preserve the older version of the kernel installed so that you can revert back to a known working version of the kernel should you encounter any problems with the new version.
  • The kernel-debuginfo package for an older kernel can safely remain installed when installing a newer version. The kernel-debuginfo must match the kernel version, variant, and architecture that created the vmcore. See the file ./vmcore and strings vmcore | fgrep -m1 ‘Linux ‘ commands in the above output.
  • In Red Hat Enterprise Linux 5, the vmlinux kernel-debuginfo package is divided into two packages: kernel-debuginfo-version.arch.rpm and kernel-debuginfo-common-version.arch.rpm. Both are required in order to perform crash dump analysis on the Red Hat Enterprise Linux 5 kernels.

Run crash

When crash is run on a vmcore, at least two arguments are always required:
<ul

  • The vmlinux file associated with the running kernel, typically found in /usr/lib/debug/lib/modules/ directory.
  • The kernel crash dump name, vmcore.

For example:

# crash /usr/lib/debug/lib/module/vmlinux

/var/crash/127.0.0.1-2007-04-30-21:38/vmcore

[…]

KERNEL: /usr/lib/debug/lib/modules/2.6.9-22.EL/vmlinux

DUMPFILE: /home/eteo/crash/127.0.0.1-2007-04-30-21:38/vmcore

CPUS: 1

DATE: Mon Apr 30 21:38:40 2007

UPTIME: 00:04:04

LOAD AVERAGE: 0.36, 0.23, 0.08

TASKS: 36

NODENAME: localhost.localdomain

RELEASE: 2.6.9-22.EL

VERSION: #1 Mon Sep 19 18:20:28 EDT 2005

MACHINE: i686 (1862 Mhz)

MEMORY: 1 GB

PANIC: “Oops: 0002 [#1]” (check log for details)

PID: 2857

COMMAND: “bash”

TASK: f7b677f0 [THREAD_INFO: f7191000]

CPU: 0

STATE: TASK_RUNNING (SYSRQ)

crash>

Setup Diskdump

Diskdump is one of the two different crash dump facilities that we shipped with Red Hat Enterprise Linux 3 and 4. This article will not cover Netdump or Kdump.

Before you beginning setting up Diskdump on your machine, do read /usr/share/doc/diskdumputils-version/README to make sure that your machine has a supported storage adapter before proceeding.

Assign a disk device to dump memory. It may be:

  • a full disk device (for Red Hat Enterprise Linux 3 only), e.g. /dev/sda
  • a partition of a disk device, e.g. /dev/sda2
  • a swap partition (for Red Hat Enterprise Linux 4 only), e.g. /dev/sda2

Define the disk device in /etc/sysconfig/diskdump. In this example, we will use /dev/sda2:

# vi /etc/sysconfig/diskdump

add the line “DEVICE=/dev/sda2”

Load the kernel module:

# tail -f /var/log/message &

# modprobe diskdump

Apr 30 21:29:20 kerndev kernel: disk_dump: Maximum block size: 16384

Apr 30 21:29:20 kerndev kernel: disk_dump: total blocks required: 261770

(header 3 + bitmap 8 + memory 261759)

See /proc/diskdump after loading diskdump kernel module:

# cat /proc/diskdump

# sample_rate: 8

# block_order: 2

# fallback_on_err: 1

# allow_risky_dumps: 1

# dump_level: 0

# total_blocks: 261770

#

Format the diskdump device:

# service diskdump initialformat

/dev/sda2: [100.0%]

See /proc/diskdump after formatting:

# tail -n2 /proc/diskdump

sda2 102398310 10233405

Enable Diskdump service:

# chkconfig diskdump on

# service diskdump start

Starting diskdump:                            [ OK ]

# Apr 30 21:31:19 kerndev diskdump: activating succeeded

Test that Diskdump works. The following commands will crash your machine:

# echo 1 > /proc/sys/kernel/sysrq

# echo c > /proc/sysrq-trigger

Make sure that you run the above two commands in console (press Ctrl + Alt + F1), so that we can see what is happening when your system crashes. You have to perform this so that you can have a vmcore file to follow the rest of the paper. It will be located at /var/crash.

Commonly Used Crash Commands

There are many commands in crash. It is also possible to extend crash by adding new commands, by writing new code and compiling it into the crash executable, or creating a shared object library that can be dynamically loaded by using the extend command. The following are some commonly used crash commands that you will likely use:

  • help – get help
    crash has a readily available help information built into the utility, by typing help. Each command has its own man-like page, which can be viewed by typing help command-name.
  • crash> help
  • *      files   mod    runq   union
  • alias  foreach mount  search vm
  • ascii  fuser   net    set    vtop
  • bt     gdb     p      sig    waitq
  • btop   help    ps     struct whatis
  • dev    irq     pte    swap   wr
  • dis    kmem    ptob   sym    q
  • eval   list    ptov   sys
  • exit   log     rd     task
  • extend mach    repeat timer
  • crash version: 4.0-3.3   gdb version: 6.1
  • For help on any command above, enter “help “.
  • For help on input options, enter “help input”.

For help on output options, enter “help output”.

Tip: all the crash commands can be piped to external programs or redirected to files:

crash> log > log.txt

This will send the in-kernel log to a local file called log.txt.

crash> ps | fgrep bash | wc -l

This will count the number of bash tasks that were running.

  • sys – system data
  • crash> sys
  •        KERNEL: /usr/lib/debug/lib/modules/2.6.9-22.EL/vmlinux
  •      DUMPFILE: /home/eteo/crash/127.0.0.1-2007-04-30-21:38/vmcore
  •          CPUS: 1
  •          DATE: Mon Apr 30 21:38:40 2007
  •        UPTIME: 00:04:04
  •  LOAD AVERAGE:  0.36, 0.23, 0.08
  •         TASKS: 36
  •      NODENAME: localhost.localdomain
  •       RELEASE: 2.6.9-22.EL
  •       VERSION: #1 Mon Sep 19 18:20:28 EDT 2005
  •       MACHINE: i686 (1862 Mhz)
  •        MEMORY: 1 GB

PANIC: “Oops: 0002 [#1]” (check log for details)

The sys messages have information of the system (e.g. kernel release, kernel version, number of CPUs, amount of memory, etc), the time of vmcore taken, the operating period, and the panic (e.g. oops type, panic task/PID/command, etc).

  • bt – backtrace
  • crash> bt
  • PID: 2857   TASK: f7b677f0 CPU: 0    COMMAND: “bash”
  •  #0 [f7191e04] start_disk_dump at f89d7bb3
  •  #1 [f7191e18] die at c010682e
  •  #2 [f7191e48] do_page_fault at c011ab00
  • […]
  •  #9 [f7191fc0] system_call at c030f918
  •     EAX: 00000004 EBX: 00000001 ECX: b7de7000 EDX: 00000002
  •     DS: 007b       ESI: 00000002 ES: 007b        EDI: b7de7000
  •     SS: 007b       ESP: bfe01650 EBP: bfe01670

CS: 0073       EIP: 003297a2 ERR: 00000004 EFLAGS: 00000246

  • log – dump system message buffer
  • crash> log
  • […]
  • SysRq : Crashing the kernel by request
  • Unable to handle kernel NULL pointer dereference at virtual address 00000000
  •  printing eip:
  • c0233fa7
  • *pde = 3e9f3067
  • Oops: 0002 [#1]
  • Modules linked in: md5 ipv6 autofs4 i2c_dev i2c_core sunrpc scsi_dump diskdump dm_mirror dm_mod button battery ac yenta_socket pcmcia_core uhci_hcd ehci_hcd shpchp snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore ipw2200 ieee80211 ieee80211_crypt tg3 floppy ext3 jbd ata_piix libata sd_mod scsi_mod
  • CPU:    0
  • EIP:    0060:[]    Not tainted VLI
  • EFLAGS: 00010246    (2.6.9-22.EL)
  • EIP is at sysrq_handle_crash+0x0/0x8
  • eax: 00000063   ebx: c0370db4    ecx: 00000000  edx: 00000000
  • esi: 00000063   edi: 00000000    ebp: 00000000  esp: f7191f60
  • ds: 007b   es: 007b    ss: 0068
  • Process bash (pid: 2857, threadinfo=f7191000 task=f7b677f0)
  • Stack: c02342d8 c032dc4e c032f105 00000003 00000002 f7b6adc0 00000002
  •        f7191fac c01a8a13 c0362740 c0168205 f7191fac b7de7000 f7b6adc0
  •        fffffff7 b7de7000 f7191000 c01682cf f7191fac 00000000 00000000
  •        00000000 00000001 00000002
  • Call Trace:
  •  [] __handle_sysrq+0x58/0xc6
  •  [] write_sysrq_trigger+0x23/0x29
  •  [] vfs_write+0xb6/0xe2
  •  [] sys_write+0x3c/0x62
  •  [] syscall_call+0x7/0xb

Code: 4c 11 42 c0 05 00 00 00 c7 05 50 11 42 c0 2f cc 31 c0 c7 05 54 11 42 c0 00 00 00 00 c7 05 58 11 42 c0 00 00 00 00 e9 e5 0b f0 ff  05 00 00 00 00 00 c3 e9 e1 59 f3 ff e9 1e bc f3 ff 85 d2 89

The log command dumps the kernel log buffer contents in chronological order. This is similar to what you would see when you type dmesg on a running machine. This is useful when you want to look at the panic or oops message. An oops is triggered by some exception. It is a dump of the CPU register’s state and kernel stack at that instant. From the panic message, we can find hints as to how the panic was triggered (e.g. the function or process or pid or command or address that triggered the panic), the register’s information, kernel module list, whether the kernel is tainted with proprietary kernel modules loaded, and so on. Let’s walk through the panic message to see what we can learn from it. See the comments below each section within the log:

crash> log

[…]

SysRq : Crashing the kernel by request <– this panic is intentional

Unable to handle kernel NULL pointer dereference at virtual address 00000000

This is the address to which reference was attempted.

printing eip:

c0233fa7

This is the address at which the failure occurred.

*pde = 3e9f3067

Oops: 0002 [#1]

Often one oops will trigger more; only the first is reliable.

Modules linked in: md5 ipv6 autofs4 i2c_dev i2c_core sunrpc scsi_dump diskdump dm_mirror dm_mod button battery ac yenta_socket pcmcia_core uhci_hcd ehci_hcd shpchp snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore ipw2200 ieee80211 ieee80211_crypt tg3 floppy ext3 jbd ata_piix libata sd_mod scsi_mod

CPU: 0

EIP: 0060:[]    Not tainted VLI

The first part is the code segment and instruction address. If tainted, it will be followed by:

G – All modules loaded have a GPL

or compatible license

P – Proprietary modules loaded

F – Module forcibly loaded

S – Oops on hardware that are not

SMP capable

R – Module forcibly unloaded

M – Machine Check Exception (MCE)

occurred

etc (see Further readings section).

EFLAGS: 00010246    (2.6.9-22.EL)

This line denotes program status, registers information.
<preMsoNormal” style=”mso-margin-top-alt:auto;mso-margin-bottom-alt:auto; margin-left:.5in;line-height:normal”>These are the stack, operations, return addresses.

f7191fac f7191000 c01682cf f7191fac 00000000 00000000 00000000

00000001 00000002

Call Trace:

This is the backtrace of function calls.

[] __handle_sysrq+0x58/0xc6

[] write_sysrq_trigger+0x23/0x29

[] vfs_write+0xb6/0xe2

[] sys_write+0x3c/0x62

[] syscall_call+0x7/0xb

Code: 4c 11 42 c0 05 00 00 00 c7 05 50 11 42 c0 2f cc 31 c0 c7 05 54 11 42 c0 00 00 00 00 c7 05 58 11 42 c0 00 00 00 00 e9 e5 0b f0 ff  05 00 00 00 00 00 c3 e9 e1 59 f3 ff e9 1e bc f3 ff 85 d2 89

From the line c0233fa7, we can see that this is the address at which the failure occurred. Issuing the following command can give us more hints as to which function or source code or assembly statement in the kernel triggered that:

crash> dis -lr c0233fa7

/usr/src/build/614745-i686/BUILD/kernel-2.6.9/linux-

2.6.9/drivers/char/sysrq.c: 115

0xc0233fa7 :        movb   $0x0,0x0

  • ps – display process status information
  • crash> ps
  •    PID    PPID CPU   TASK   ST %MEM  VSZ  RSS COMM
  •       0      0  0 c0358be0  RU  0.0    0    0 [swapper]
  •       1      0  0 f7e01770  IN  0.1 1680  684 init
  • […]
  •    2380      1  0  f7ac2800 IN  0.0 1604  504 mingetty
  •    2769   2371  0  f7ac3970 IN  0.2 5740 1636 bash
  •    2852      1  0  f7b1a880 IN  0.2 4240 2012 sshd
  •   2855 2852 0 f7b66680 IN 0.3 8316 2756 sshd
  • > 2857 2855 0 f7b677f0 RU 0.2 6260 1628 bash
  • Sometimes it is useful to know which process belongs to which parent or vice versa. ps has -c and -p to show the child and parent processes.
  • crash> ps -p 2857
  • PID: 0       TASK: c0358be0 CPU: 0    COMMAND: “swapper”
  •  PID: 1       TASK: f7e01770 CPU: 0    COMMAND: “init”
  •   PID: 2852    TASK: f7b1a880 CPU: 0    COMMAND: “sshd”
  •    PID: 2855    TASK: f7b66680 CPU: 0    COMMAND: “sshd”

PID: 2857    TASK: f7b677f0 CPU: 0    COMMAND: “bash”

 

  • files – open files
  • crash> files
  • PID: 2857    TASK: f7b677f0 CPU: 0   COMMAND: “bash”
  • ROOT: /     CWD: /root
  •  FD    FILE      DENTRY    INODE   TYPE  PATH
  •   0 f7a6e7c0 f7790198 f7b0fdcc     CHR   /dev/pts/0
  •   1 f7b6adc0 f7190130 f7b9ca4c     REG   /proc/sysrq-trigger
  •   2 f7a6e7c0 f7790198 f7b0fdcc     CHR   /dev/pts/0
  •  10 f7a6e7c0 f7790198 f7b0fdcc     CHR   /dev/pts/0
  • 255 f7a6e7c0 f7790198 f7b0fdcc     CHR   /dev/pts/0
  • crash> files 2852
  • PID: 2852    TASK: f7b1a880 CPU: 0   COMMAND: “sshd”
  • ROOT: /     CWD: /
  •  FD    FILE      DENTRY    INODE   TYPE  PATH
  •   0 f7b336c0 f78001d8 f7cb1ba4     CHR   /dev/null
  •   1 f7b336c0 f78001d8 f7cb1ba4     CHR   /dev/null
  •   2 f7b336c0 f78001d8 f7cb1ba4     CHR   /dev/null

3 f7b69600 f7bf5280 f7aadafc     SOCK  socket:/[6277]

  • dev – device data
  • crash> help dev
  • […]
  •  If no argument is entered, this command dumps the contents of the
  •  chrdevs and blkdevs arrays.
  • crash> dev
  • CHRDEV    NAME         OPERATIONS
  •  1      mem              (none)
  •  4      /dev/vc/0        (none)
  •  4      tty              (none)
  • […]
  • BLKDEV     NAME        OPERATIONS
  •  1      ramdisk        c0376d08
  •  2      fd            (unknown)

8      sd             f880e070

Categories
Linux

Windows 8 OEM specs may block Linux booting

After years of trying to cut off Linux growth as a desktop platform on x86 and x64 PCs, Microsoft may have actually figured out a way to stop Linux deployments on client PCs dead in their tracks.

 

At the very least, Linux deployment will be hindered on any Windows 8-certified machines to come, as new requirements for the Windows 8 logo come to light.

 

Red Hat’s Matthew Garrett was one of the first to notice that according to the new logo rules, all Windows 8 machines will need to be have the Unified Extensible Firmware Interface (UEFI) instead of the venerable BIOS firmware layer. BIOS has been pretty much the sole firmware interface for PCs for a long time.

 

The EFI system has slowly been making headway in recent years, and right now EFI firmware is compatible with Windows supporting the GUID Partition Table (GPT), OS X/Intel, and Linux 2.6 and beyond machines. EFI is seen as a better hardware/software interface than BIOS, since it is platform-agnostic, runs in 32- or 64-bit mode, and GPT machines can handle boot partitions of up to 9.4 zettabytes. (That’s 9.5 billion terabytes to you and me.)

 

EFI, and the later UEFI specification, is not the problem for Linux. The problem is Microsoft’s other requirement for any Windows 8-certified client: the system must support secure booting. This hardened boot means that “all firmware and software in the boot process must be signed by a trusted Certificate Authority (CA),” according to slides from a recent presentation on the UEFI boot process made by Arie van der Hoeven, Microsoft Principal Lead Program Manager.

 

The slides, posted on Garrett’s in a blog Tuesday afternoon, reveal Microsoft’s plan to lock down the boot process, which Microsoft rightly points out has become a high-value target vector for injecting malware onto Windows PCs. To combat this, Microsoft is requiring all Windows 8 devices to have a hardened boot. Right now, even though there are EFI-ready Linux bootloaders and distros available, none of them are signed, Garrett reminded me.

 

It’s not just a matter of replacing the UEFI system on the device with other, unencrypted, firmware. If all parts of the chain need to have a CA signature, then swapping out a machine’s signed EFI layer with, say, an unsigned BIOS or EFI would not work. Garrett described the problem in more detail:

“Microsoft requires that machines conforming to the Windows 8 logo program and running a client version of Windows 8 ship with secure boot enabled. The two alternatives here are for Windows to be signed with a Microsoft key and for the public part of that key to be included with all systems, or alternatively for each OEM to include their own key and sign the pre-installed versions of Windows. The second approach would make it impossible to run boxed copies of Windows on Windows logo hardware, and also impossible to install new versions of Windows unless your OEM provided a new signed copy. The former seems more likely.”

 

The upshot? Any device that ships with the manufacturer’s keys and Microsoft’s keys will not be able to boot a vanilla version of Linux.

 

The obvious solution–getting Linux distros signed so they can load on these machines–is clouded with uncertainty.

“Firstly, we’d need a non-GPL bootloader. Grub 2 is released under the GPLv3, which explicitly requires that we provide the signing keys. Grub is under GPLv2 which lacks the explicit requirement for keys, but it could be argued that the requirement for the scripts used to control compilation includes that. It’s a grey area, and exploiting it would be a pretty good show of bad faith. Secondly, in the near future the design of the kernel will mean that the kernel itself is part of the bootloader. This means that kernels will also have to be signed. Making it impossible for users or developers to build their own kernels is not practical. Finally, if we self-sign, it’s still necessary to get our keys included by ever OEM.”

 

That’s a whole lot of unsavory options to look forward to.

 

Garrett, for his part, is not panicking about the new requirement. He’s hopeful that OEMs will be able to include an option in their UEFI firmware to disable the secure booting feature. Even if that is allowed by Microsoft, one thing is clear: dual-booting systems will be out of the picture if Windows 8 boots always require a hardened boot environment. It may very well be that once you turn off secure boot (if you can), you won’t be able to run Windows 8 again on that machine, until you re-secure the boot process.

 

Microsoft is spinning this as a way to finally lock down the boot process, but I can’t help but wonder if the side-benefit of blocking Linux boots was something expected as well.

 

Something to which we need to pay attention, that’s for sure.

Courtesy: http://www.itworld.com/it-managementstrategy/205255/windows-8-oem-specs-may-block-linux-booting

Categories
technews

Google Wallet goes live

At long last, Google has launched its Google Wallet mobile payment application on Sprint Nexus S 4G smartphones.

Google Wallet, which Google first announced this past spring, utilizes near-field communications (NFC) technology to send very short-range signals to nearby NFC tags to complete payments — or as Google tells it, you’ll only have to tap your smartphone on a store’s credit card processor and you’re good to go. For now the application will only be available to use on the Sprint network with the Nexus S 4G device, although Google says the app should come to other Android-based devices on other wireless networks in the near future.

In its initial incarnation, Google Wallet lets you pay for merchandise using either a Citi MasterCard or a Google Prepaid Card that Google says “can be funded with any of your existing plastic credit cards.” Google is giving users a $10 bonus if they set up their own Google Prepaid Card by the end of the year. During its initial announcement of Google Wallet, Google said that it had lined up 15 big-name merchants that have embedded Google Wallet NFC capabilities onto their stores’ credit card processors, including RadioShack, American Eagle Outfitters, Subway, Macy’s, Foot Locker and Walgreens.

From a security standpoint, Google is emphasizing three of the application’s key features that will help you keep your virtual wallet secure. The first is a simple PIN that Google says you’ll need to enter before making any purchase; or put another way, the same basic security measure that you enact every time you pay with your debit card. Google has also created a separate chip for its Wallet called Secure Element that stores encrypted credit card data and that is separate from your smartphones memory and that the company says will “self-destruct” if anyone tampers with it. And finally, Google is also using MasterCard’s PayPass technology to encrypt your credit card information as it’s being sent from your phone to an NFC tag.

NFC payments have become a hot feature on smartphones ever since Google first enabled NFC technology on its Android operating system when it released its Android 2.3 (“Gingerbread”) update last year. Online payment company PayPal has also developed an NFC-based mobile payment application that runs on the Google Nexus Smartphone.

 

 

 

Categories
technews

Carol Bartz out as Yahoo CEO

 Carol Bartz has been fired from her job as Yahoo CEO and replaced on an interim basis by the company’s chief financial officer, Tim Morse, Yahoo said on Tuesday.

Bartz sent a brief e-mail to employees saying she had been fired by Yahoo’s chairman, according to the Wall Street Journal’s All Things D blog, which was the first to report her departure.

“I am very sad to tell you that I’ve just been fired over the phone by Yahoo’s Chairman of the Board. It has been my pleasure to work with all of you and I wish you only the best going forward,” Bartz wrote.

The struggling search company has created an “executive leadership council” to help Morse run the company and to conduct a “comprehensive strategic review” aimed at getting Yahoo back on a growth track. The council includes Yahoo co-founders Jerry Yang and David Filo.

Bartz’s tenure as CEO began in January 2009 after Yang announced plans to step down. She took over following an extensive courtship in which Microsoft tried to acquire Yahoo, but which eventually turned into a partnership between the companies.

That partnership hasn’t paid off as well as Yahoo hoped. Revenue at the company continues to fall, and its display advertising business, where it historically was a leader, has begun to suffer too.

“It’s not a surprise” to see Bartz go, said Greg Sterling, an analyst at Sterling Market Intelligence.

At the company’s recent annual meeting, a shareholder called Bartz a “lame-duck CEO” and called for her resignation. Yahoo Chairman Roy Bostock defended her at the time.

Bartz was widely supported in the beginning. “She was kind of a breath of fresh air for a while,” said Sterling. She had a strong track record as CEO of Autodesk and before that as an executive at Sun Microsystems, and had a “no-nonsense” style, Sterling said. She was known for her colorful language and dropped the “F-bomb” at least once during a company earnings call.

Bartz made a number of organizational changes and for a while had the bad economy to blame for Yahoo’s lackluster performance, Sterling said. But ultimately she failed to retain some top talent who have left the company since she took over. “There were just a ton of great people that came out of there that abandoned ship,” he said.

Yahoo needs a dynamic leader who will get people excited and bring a strong product vision, Sterling said. Morse would clearly be an interim leader while the company looks to hire a permanent replacement, he said.

Taking on a new leader while the company continues to struggle will be a challenge. “The problem with a new CEO is if you have more of a revolving door,” Sterling said. Often, new leaders want to bring in their trusted advisers and remove some existing executives.

In a statement, Bostock thanked Bartz for “her service to Yahoo! during a critical time of transition in the company’s history, and against a very challenging macro-economic backdrop.”

At the time of this report, Yahoo’s shares were up more than 6 percent in after-hours trading, at $13.72.

Categories
technews

GlobalSign is no longer issuing digital certificates as it investigates the incident

Digital certificates issued by GlobalSign have come under scrutiny after a hacker’s claim that he broke into the company’s computer systems. If true, it would be the second such compromise in the past few weeks.

The hacker, known as Comodohacker, said on Monday he had broken into Dutch certificate authority (CA) DigiNotar and that he had access to four other such companies, including GlobalSign, a certificate authority based in Portsmouth, New Hampshire. On Tuesday, GlobalSign said it was investigating the claim and had “decided to temporarily cease issuance of all certificates until the investigation is complete.”

“We will post updates as frequently as possible,” the company said in a post to its website. “We apologize for any inconvenience.”

GlobalSign couldn’t immediately be reached for comment, but earlier in the day, Steve Roylance, GlobalSign’s business development director, said his company was “taking this very seriously.”

Comodohacker, also known as Ich Sun, is the person who earlier this year claimed to have broken into security vendor and certificate issuer Comodo. At the time he said he was a 21-year-old student who had also compromised another certificate authority, but he didn’t name his other victim.

Little noticed by most Web surfers, digital certificates are an important part of the Internet’s foundations. They help browsers know when they are visiting legitimate websites rather than fakes.

A country that has control over its Internet service providers and has access to fake digital certificates could create a website that would be almost impossible to distinguish from, for example, Gmail.com. That’s what some experts think happened in Iran last month.

A forensics report commissioned by DigiNotar found someone had hacked into DigiNotar and set up a fake Google.com site that was used in late July and August to spy on as many as 300,000 Iranians.

Most browsers no longer trust the DigiNotar certificates, but if Comodohacker’s claims are true there could be further problems in store.