Using 3G USB mobile network sticks with USB 3.0 ports (Ubuntu/Linux)

I struggled for a while with my new laptop with Ubuntu 14.04: I could not understand why none of my 3G USB keys worked on it.

UPDATED (see bottom)

In /var/log/syslog I could see it being recognized, and a line mentioning usb_modeswitch… except no mode switching was happening: the ProductId was did not change, and so obviously no network.

I have the latest usb-modeswitch-data installed, and my card’s VendorId and ProductID are in it (It’s a Huawei Vodafone K4605, 12d1:14c1), apparently… but nope, no mode switching: I get a usb-storage device, and that’s all.

Long story short, this is the workaround I found, until some permanent fix is issued by Ubuntu: after inserting the card wait for a few seconds and then run a command like this one:

sudo usb_modeswitch -v 12d1 -p 14c1 -M '55534243123456780000000000000011062000000100000000000000000000'

(all on one line, substitute the VendorID and ProductID with your key’s)

This is pretty much what udev should be doing on itself, but for some reason it’s not.

…and bam! After a few more seconds you will be able to configure and use the Mobile Broadband connection in NetworkManager.

It took me some time to figure this out, so I hope it will help someone else, too.


 

Update: I got my hands on a more recent 3G key (a Vodafone Huawei K4201) and lo and behold, it works out of the box… it’s a weird device though; it presents itself to the system as a wired connection (ethernet), has a DHCP server and assigns a 192.168.9.0/24 address, which could be a problem (not in my case, but… horrible choice of network, Vodafone!).

Using Adwaita Dark for your linux desktop: fixing the desktop icon color.

I was getting a bit tired of the old grey gradients of the default Gnome3 theme in Fedora 16 (Adwaita) so I poked around and found that there is a hacked Adwaita Dark theme that uses the color scheme you see in a couple of multimedia apps in regular Adwaita for all the desktop (basically, turns everything dark).

You can download it from this website.

It looks pretty spiffy, but it has a small drawback: if you’re using Nautilus icons on the desktop (which is notย the default in Gnome3) the icon names have a very dark text. This was probably overlooked because the original author wasn’t using them.

Here is the easy fix: go to your Adwaita Dark theme’s gtk-3.0 folder (probably ~/.themes/Adwaita Dark/ ) and edit gnome-applications.css with your favorite text editor and change the .nautilus-desktop.nautilus-canvas-item selector like this:

.nautilus-desktop.nautilus-canvas-item {
 /* Was Originally:
 * color: @theme_bg_color;
 */ย 
/* Fixed version: */
color: @theme_text_color;
/* End of the fix */
text-shadow:1 1 black;
}

Yes, it’s really that easy: one line of CSS!

The theme should update in realtime. If it doesn’t try changing it and back, or logging out. Enjoy!

Changing the Gnome Keyring unlock password

The Gnome keyring has had for some time the nice feature to unlock itself upon login. Unfortunately as soon as you change your password (which you could be forced to, due to company policy, for example) it stops, since the keyring password is now out of sync.

For some time it was simply impossible to change the unlock password (yeah, annoying).

Then the change password dialog was implemented in Seahorse ( yum install seahorse seahorse-plugins )… but this feature is not only very poorly documented (if at all), all the online pointers and fourm posts talk about an old version of Seahorse apparently.

In Fedora 10 the functionality is there, but it is a bit hidden: install seahorse, click Applications -> Accessories -> Passwords and Encription Keys

then click on Edit, Preferences, and there you are, the “login” line with the big “Change Unlock Password” button. Now you simply have to insert the old password, and update it with your current one.

Change Gnome Keyring Unlock Password
Change Gnome Keyring Unlock Password

Enjoy!

Why no ssh-vulnkey for non-ubuntu systems?

I mean, it’s not like the problem is only on ubuntu/debian machines. I’d like to be able to check if the keys installed on my (non-debian and non-ubuntu… some even non-linux) servers are vulnerable.

What’s really nasty of this debian ssh mess is that the vulnerability was born on the debian clients, and spreads making all the (non necessarily debian) servers where they are installed to.

So, do I have to dl ubuntu’s openssh .debs and extract ssh-vunlkey from there? That’s not really nice ๐Ÿ™‚

–UPDATE–

Apparently there’s some huge perl script here

http://ubuntu-tutorials.com/category/security/

that should do the job… checking…

Using an EMC CX3-10 Storage with CentOS5

I have had the mixed pleasure of setting up an EMC CX3-10 Storage (fibrechannel and iSCSI) on a couple of CentOS5 machines, lately, and I’m going to share here the tweaks I had to make to the provided software. I hope this will come handy to someone else on the planet.

Before you proceed, the standard disclaimer:
If you break your costly servers and storage appliances using these instructions, you can keep the pieces. This is simply my experience, use at your own risk, and don’t come crying if you mess up ๐Ÿ™‚

The Drivers

CentOS5 recognized the HBA cards right away, so no sweat here. Hey, it’s RedHat Enterprise 5, after all, under the hood.

The EMC CX3-10 Storage comes with a couple of packages (namely NaviSphere and PowerPath) that install drivers and stuff so that the system can see the disks correctly. And here comes the quirky part: the software has to ensure that it’s been installed on a supported platform, and while RHEL5 is officially supported, CentOS5 is not: the software refuses to start, and if started manually it spews a phrase like “Ensure to install this software on a RedHat Enterprise machine”, or something.

Now, we all know CentOS is binary compatible with RHEL… what’s missing?

I’ll tell you what: the software is performing some tests that are a wee bit too clever… to work around them, perform these steps:

First things first, edit the file /etc/redhat-release and put in the single line
Red Hat Enterprise Linux Server release 5 (Tikanga)
so that the system is now identifying itself as a RHEL machine.

But it’s not enough for PowerPath;

Edit the file /etc/opt/emcpower/EMCpower.LINUX-5.0.1/enable, and substitute the lines that say

rhel_version=`rpm -qf /etc/issue | \
sed 's/redhat-release-\([0-9]\)Server.*/\1/'`

with these:

rhel_version=`rpm -qf /etc/issue | \
sed 's/centos-release-\([0-9]\).*/\1/'`

This way the script will be able to find the ‘5’ version number in the name of the package it is seeking (which is centos-release, instead of redhat-release).

The init scripts

The provided init scripts are a bit amateurish, to say the least, but proprietary software vendors are not really known for their ability to comply to the LSB specifications… even when they want them as mandatory…

So, edit the file /ect/init.d/PowerPath and add the line
# chkconfig: 345 20 40
just above the one that starts with # description:. Then, use the command chkconfig --add PowerPath to make that service manageable from the standard LSB tools. Just to be sure, also use
chkconfig PowerPath reset

chkconfig PowerPath on
chkconfig --list | grep PowerPath
and check that the service is configured as on.

Other than that, follow the normal instructions, and make sure that the naviagent service starts before the PowerPath service, which it should if you are using my numbers: naviagent already has LSB start and stop priorities, and they by default 25 and 35.

Checkinstall for gnome packets

Checkinstall is a very useful package for linux distros that track their packages with databases (that is, with rpm or deb packages) when compiling from source, and can save you a lot of headaches when uninstalling or upgrading a package.

But I’ve found a nasty twist (not exactly checkinstall’s fault, actually) that should be kept in mind: there are some files that should NOT belong in your package. And not only for tidyness reasons, but to avoid completely screwing up your Gnome installation.

Read on…

Continue reading “Checkinstall for gnome packets”

Weird fedora dbus bug

A couple of days ago I got bit by a nasty and pretty dumb bug in dbus on Fedora Core 6: the service would just hang forever on startup.

To make a long story short, it all goes down to some interaction (I have no idea about) between dbus and ldap (of all things): if the ldap server is not available the servie just hangs.

To make the bug go away simply disable the use of ldap for “User Information” in system-config-authentication. It looks like you can continue to use it for authentication, fortunately.