Eye-Fi Connect X2 mini review/recommendation

Summary:

Eys-Fi makes a nice little SD card with built-in wifi called an Eye-Fi Connect X2 among others. This little gem is great! The title should really be, "Amazing geek toy and CYA device"...
I find the Eye-Fi Connect X2 card and Android Eye-Fi App to be very useful and mostly reliable on my Samsung Galaxy Tab Plus GT-P6210 running both the original Android 3.2 Honeycomb and recently updated Ice Cream Sandwich. There is a great deal of comfort knowing I have an immediate backup copy of every picture I take. 

Background:

Since pictures are of major importance to me. Safeguarding my photos with multiple copies is a priority. Under normal circumstance, I would take some random number of pictures, head to my laptop or home system, copy the pictures, rotate out the SD card, take more pictures, etc.

I had an original Eye-Fi card from a couple of years ago. I tried a couple of the Linux options like the python powered eyefiserver with some luck. Sadly, at the time, this option was not very portable since it needed an access point plus laptop or similar. Besides, reading the original eye-fi card was a pain for me under Linux.

Skip ahead a couple of years and the X2 versions... and add a tablet or smart phone and Ad-hoc network support of wireless uploads... welcome to a whole new world.

Now with my Android powered phone or my great little Samsung Galaxy Tab Plus GT-P6210 and the Android Eye-Fi App (or IOS App), I just start the App, shoot a pic and have an original sized copy on my phone or tablet!

OK there's a bit more to process of course. Some will not like the *requirement* to have an Eye-Fi account to use the app. Others will note that I needed to register the SD card with a Windows system. I wish that was different, but it's not.

Just as a side note, the Ad-hoc network range was about 40-45 feet as a general rule for quick transfers. As the distance got just past this range, the time to upload increased by minute(s). So, proximity does matter as you would expect for such a tiny device. Also, I did have a couple of times that the Ad-hoc network would not connect. Restarting the app seemed to provide relief.

OMSA 7.0 firmware update issue or holdover public key problem from 2010?

Updated Dell's OMSA from 6.5.1 to 7.0 via  standard yum process. Checked for any new goodies via "yum install $(bootstrap_firmware)". Tried to update firmware, but failed:

# update_firmware  --yes
Running system inventory...
Searching storage directory for available BIOS updates...
Checking BIOS - 6.1.0
Available: dell_dup_componentid_00159 - 6.1.0
Did not find a newer package to install that meets all installation checks.
Checking SAS/SATA Backplane 0:0 Backplane Firmware - 1.07
Available: dell_dup_componentid_11204 - 1.07
Did not find a newer package to install that meets all installation checks.
Checking PERC 6/i Integrated Controller 0 Firmware - 6.3.1-0003
Available: pci_firmware(ven_0x1000_dev_0x0060_subven_0x1028_subdev_0x1f0c) - 6.3.1-0003
Did not find a newer package to install that meets all installation checks.
Checking OS Drivers - 0
Available: dell_dup_componentid_18981 - 7.0.0.4
Found Update: dell_dup_componentid_18981 - 7.0.0.4
Checking Dell Lifecycle Controller - 1.5.1.57
Available: dell_dup_componentid_18980 - 1.5.2.32
Found Update: dell_dup_componentid_18980 - 1.5.2.32
Checking NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth1) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Found Update: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Checking NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth0) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Found Update: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Checking ST3450857SS Firmware - es65
Available: dell_dup_componentid_20795 - es65
Did not find a newer package to install that meets all installation checks.
Checking iDRAC6 - 1.80
Available: dell_dup_componentid_20137 - 1.85
Found Update: dell_dup_componentid_20137 - 1.85
Checking NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth2) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Found Update: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Checking NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth3) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Found Update: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Checking Dell 32 Bit Diagnostics - 5154a0
Available: dell_dup_componentid_00196 - 5154a0
Did not find a newer package to install that meets all installation checks.
Checking System BIOS for PowerEdge R710 - 6.1.0
Available: system_bios(ven_0x1028_dev_0x0235) - 3.0.0
Did not find a newer package to install that meets all installation checks.
Found firmware which needs to be updated.
Running updates...
/ Installing dell_dup_componentid_18981 - 7.0.0.4Installation failed for package: dell_dup_componentid_18981 - 7.0.0.4
aborting update...
The error message from the low-level command was:
Update Failure: Partition Failure - The Delete Dynamic Partition has failed

Tried the /etc/redhat-release fix without success. Tried a reboot to flush out any oddities...

After much google'n it seems that I had some kind of public key issue:

rpm --import http://linux.dell.com/files/libsmbios/download/RPM-GPG-KEY-libsmbios
rpm --import http://lists.us.dell.com/linux-security-publickey.txt

Now update_firmware works again as expected.

CentOS 6.3 mdadm won't start older md arrays.

For some of us, the drive setups we create stays with a system for a long time. Keeping the same data disk array untouched even for major revision changes is common (like a OS rebuild of 5.x -> 6.x). Sometimes that long term usage bites back. Here is my failure case while upgrading from CentOS 6.2 -> CentOS 6.3.

Symptoms:
Simply md RAID 1 extra data drive will not boot. The system drops to recovery mode with a missing (md) drive to mount and an fsck request. The extra file system has 2 "linux_raid_member" drives that show under fdisk and blkid. Even a "cat /proc/mdstat" shows no arrays. If I run, as root:

mdadm --auto-detect

the /proc/mdstat will finally show info, however.

Solutions:

1. Make sure that the /etc/mdadm.conf contains the array info from: 

   
   mdadm --examine --scan >> /etc/mdadm.conf
   
   

2. There seems to be kinda "depreciated" mdadm technical note about older created arrays with BZ-788022 implicated and a "+0.90" needing to be added to/etc/mdadm.conf, but you need to get rid of the "+1.x -all" options!

How do you tell in advance that you will have an issue *before* an upgrade? If  you run, as root,

mdadm -E /dev/sdc1|grep Vers

and get output like: "Version : 0.90.00", you will want to make a change *before* you reboot!

It is interesting to note that I was able to just have this md array work in 6.0, 6.1 and 6.2 because,

In Red Hat Enterprise Linux 6.1 and 6.2, mdadm always assembled version 0.90 RAID arrays automatically due to a bug.

"DEFROUTE" in RHEL, CentOS or Fedora - a usage case for eth0

Here is the situation: There is a user with a remote office that includes networking equipment like printers, backup server etc. He uses a company provided CentOS laptop as the gateway for his network via a cell card since there is no other cheaper option available to get him connected. He travels with the laptop often and I don't need access to the equipment at his office unless he's there. The user always connects either via WIFI or a cell card for VPN connection depending on what is available. The laptop is running openvpn and is connecting to our company's openvpn server. No problem... until I want to also connect the laptops ethernet cable and use NetworkManager and use a DHCP server for the eth0... That's when the VPN drops and the laptop now has an incorrect default route. What's odd is that order of interface startup does not matter... dhcp on eth0 wins no matter what... bummer.


What's happening? Well, normally with DHCP, the client is given a default route as part of the information exchange. That eth0 default route takes over. It's just that simple... unless you give the networking system guidance on what to do in the form of the "DEFROUTE" option. The option has been around for a long time. The current Red Hat Enterprise Linux 6 Deployment Guide has DEFROUTE option hidden in the 8.2.4. Dialup Interfaces section. Here is a chunk of the information from the guide:

DEFROUTE=answer

where answer is one of the following:

• yes — Set this interface as the default route.
• no — Do not set this interface as the default route.         

In the past, I did not use the DEFROUTE option. I found that I could just statically assign the eth0 and *not* let NetworkManager have access to it (NM_CONTROLLED=no). In fact with Centos (and the like), NM seems to get disabled as a generally rule.

Also, if this was a server or I wanted to statically assign the interface, it would not be an issue. Just one of those fringe usage cases.

LTSP 5.2.x rsh server on client install, setup and HOWTO

Don't start with the, "rsh is bad..." message. I know, I know! It's an internal test network and was just easy to do for remote client checking. Besides, the "ltsp-localapps" only works for the logged in user and does not allow for arbitrary root user interaction with the client. If there is a built-in way to do this, let me know. At some point, I may try sshd client setup.

I am using CentOS 6.x as the server OS and customize the client build to be CentOS 6.x also. LTSP 5.2 is the software from k12linux at fedorahostedI don't think that affects the directions below in any way, however. And if this looks like part of a script, you would be correct.

Change the LTS_HOME variable to your own LTSP client build location on the server as required:

export LTS_HOME="/opt/ltsp/i386"

Check to make sure rsh is allowed in securetty for the client:

grep -q "^rsh" $LTS_HOME/etc/securetty && echo rsh >> $LTS_HOME/etc/securetty

Get rsh-server installed into you chroot'd environment:

Option 1 (re)creates the client build to have rsh-server instaled and includes future builds:

edit the "/etc/ltsp/kickstart/Fedora/common/release/el6.ks" and add "rsh-server" *before* the "%end" line. Then (re)run the ltsp-build-client and ltsp-server-tweaks as if a new install:

ltsp-build-client 2>&1 |tee /tmp/ltsp-build-client.out-`date +%Y%m%d%H%M`


cd $LTS_HOME

setarch i386 chroot .


chkconfig rsh on

ltsp-server-tweaks

Option 2 install and setup the rsh-server for this client build only:

cd $LTS_HOME

setarch i386 chroot .

mount -t proc proc /proc

#set proxy if needed

yum install rsh-server

chkconfig rsh on

umount /proc

Get the clients /root to be based on the $LTS_HOME/root from the server and not a tmpfs by commenting the "/root" line of k12linux.rwtab:

sed -i 's/^empty[[:space:]]\/root/#empty\t\/root/'$LTS_HOME/etc/rwtab.d/k12linux.rwtab

OR for you perl peeps

perl -p -i -e "s/^empty\t\/root/\#empty\t\/root/g" $LTS_HOME/etc/rwtab.d/k12linux.rwtab

Note: To safeguard your custom options from accidental rpm update overwrites, please consider creating your own blah.ks file to be referenced in /etc/ltsp/ltsp-build-client.conf.

Properly create a .rhosts file for the clients root user. This script chunk assumes the primary (eth0) interface is the interface that communicates with the clients. If your primary server interface is not the interface for client connection, you will need to add/modify the client's .rhosts file accordingly:

echo "server-`hostname --ip` root" >> $LTS_HOME/root/.rhosts
echo "rsh" >> $LTS_HOME/etc/securetty
chmod 600  $LTS_HOME/root/.rhosts

Now boot the client and test an rsh command from the server to the client. If you have issues, you will want to add a "shell" option for the client in the correct lts.conf then reboot the client. For i386 arch, the file is "/var/lib/tftpboot/ltsp/i386/lts.conf". This will give you a chance to see the /var/log/messages file if you have not setup remote logging for the client.

To make a custom PXE boot logo change, create/modify a theme run the following command from within the chroot:
ltsp-rewrap-latest-kernel

To apply a new theme
Create a new plymouth theme. You can do this by making simple variations on the stock theme by taking a copy of the default theme using the procedure below. You can replace "newtheme" in the commands below with whatever name you want to give the new theme. This procedure assumes the chroot is in the /opt/ltsp/i386 directory.

Start by copying the folder with this command:

cp -a /opt/ltsp/i386/usr/share/plymouth/themes/solar /opt/ltsp/i386/usr/share/plymouth/themes/newtheme

Now modify "newtheme" as appropriate. First go into the new theme directory by typing:

cd /opt/ltsp/i386/usr/share/plymouth/themes/newtheme

Then rename the .plymouth file by running:

mv rings.plymouth newtheme.plymouth

Edit the .plymouth file and change:

Name=Rings

to:

Name=Newtheme

and change:

ImageDir=/usr/share/plymouth/themes/rings

to

ImageDir=/usr/share/plymouth/themes/newtheme

You may also want to change the background colors. BackgroundStartColor is the color at the top of the screen and BackgroundEndColor is the color at the bottom of the screen. Plymouth will make a gradient of these colors across the screen. For example to make the background change from white to black change the lines:

BackgroundStartColor=0x080808
BackgroundEndColor=0x080808

to:

BackgroundStartColor=0xffffff
BackgroundEndColor=0x000000

When finished making changes save the file.

Next replace the image file named header-image.png with the desired replacement. Do not change the name of this file!

The exact size does not seem to matter as the plymouth will center it in the screen above the animated "rings".

You can also get fancy and replace all the other progress images also.

Chroot to the client directory by running:

chroot /opt/ltsp/i386

Activate the new theme with this command:

plymouth-set-default-theme newtheme

Note: you may get an error from sed (ex: sed: warning: failed to set default file creation context to unconfined_u:object_r:usr_t:s0: No such file or directory). This does not seem to cause problems.

Build a new initramfs file with the new theme:

ltsp-rewrap-latest-kernel

Exit the chroot by typing:

exit

and update the tftp directory with the new initramfs by typing:

ltsp-update-kernels

If you use NBD you will also need to run:

ltsp-update-image

Now fire up a client and enjoy the new theme!

Static DHCP is better than IP address assignment on a device

//BEGIN RANT//

Attention standalone network attached device vendors like large copier manufacturers:

Please train your onsite personnel in understanding that a DHCP assigned address is not always a "Dynamic" address. Please help them understand that there is such a beast as "Static Allocation DHCP" or "Address Reservation". And that Static DHCP gives the equipment *the same address* every time. And help them realize that the equipment will work just fine on the network and won't magically just break. And that I can change every part of the network properties without touching the dumb box or it's crappy web/console interface. Please also train them to not go behind a client's back who gives explicit instructions on keeping the DHCP option enabled (and then enabling a static address on the device).

//END RANT//

JShot - multiplatform screen capture and annotator

Recently, I needed to do a minor amount of screen annotation. I was very pleased to have found JShot for my Linux system. As quoted from the website,

"JShot is a free and multiplatform screen capture and uploader application which allows you to capture and annotate a part of your screen and share it via the Internet in one step."

And as luck would have it, one of the upload options is for Google's Picasaweb that helps provide images for Blogger.

JShot is a usefully featured screen capture program. It is fast in screen, area or region capture. JShot has an optional toolbar dock that lets you quickly take the screenshot you want. There are several easy to select and use annotation tools. The tools include circles, ovals, squares, rectangles, arrows or text. I like the transparency and highlight options for those tools. Arrows and text input pivot and rotate with little effort. Text input font is easy to modify.

JShot will also open arbitrary image files for annotation beyond just the screenshot image taken. Nice additional features include the mentioned Picasaweb single click upload as well as FTP or Dropbox to name just a couple. You can even free-hand draw on your screen prior to screen capture (yes that is close to my normal handwriting scribble).

JShot also includes an extendable plugin capability for those needing something more. Did I mention the Java Web Start option?

There are just a couple of minor issues from my usage attempts. First, large images can not be scaled to fit on the screen. Also, the shapes can not be rotated (not that you rotate a circle). They move on an vertical or horizontal axis only. The "File" -> "Open" dialog does not remember last settings (for stuff like this, the date sort is more often what I want). I would also like to see the auto-number name incrementing that other screen capture utilities have like ksnapshot.  Another only slightly annoyance is the "File" -> "Exit" produces a "All unsaved data will be lost" message even if you *just* saved. Fairly nit-picky issues overall. None outweigh the very useful capability.

I have not been much of a java app fan, but JShot is a very well done utility that will remain in my Linux geek toolbox. Hope you enjoy this utility as much as I have. And just to be clear, JShot screen capture and annotator works for Mac, Windows and Linux.