linux


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!

This tool sounds really handy for clever tricks (and horrid hacks)

http://www.redhatmagazine.com/2007/12/04/hacking-rpms-with-rpmrebuild/

Basically you can modify the spec file inside an rpm on the fly, or rebuild a package from the existing files on your system (with your customized settings files, for example).

Nice.

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…

Fedora User? Then this article will be golden for you:

12 YUM Tips and Tricks written by Fedora developer Mohd Izhar Firdaus Ismail

A nice breakdown of little known tricks to use with the (very nice and powerful) Fedora package manager.

Enjoy!

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 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…

(more…)

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.