Pablo Endres’s Blog

I just tested the latest version of VMware Workstation for Linux on my Fedora 11 box and there are a couple of things that just bothered me.  The big picture is that it’s not working smoothly:

The problems started on install time, in order to be able to install the rpm I had to uninstall gcc! (Thanks to Tusheto for the idea ).  Then I could work as usual with your virtual machines until I tried to turn them off:  it hung forever, I gave it 5 min. before having to kill window.  The files stayed locked thanks to the vmtray that is not shown in GNOME, so if happen to have you VM’s in a external drive there is no way to cleanly unplugg it without killing the residual process.

Afer so many years working with VMware on Linux I really expected more.  Rating F

Ran my tests on Fedora 11, kernel: 2.6.30.5-43.fc11.i686.PAE, and VMware-Workstation-6.5.3-185404.i386

This feature just popped up and started working after I upgraded to Fedora 10 and I though it was a standard function in gnome, but I was working with Per the other day and his Ubuntu 8.04 didn’t have it running out of the box.  So I had to take a look a the docs to make it work:  http://live.gnome.org/GnomeKeyring/Ssh

This is just one of those features that make your life easier but handling all the ssh sessions for you, the best part is that is one of those setup once and forget feature.  Here is a brief introduction on how it works:

According to the ssh-agent man:

     ssh-agent is a program to hold private keys used for public key authenti-
     cation (RSA, DSA).  The idea is that ssh-agent is started in the begin-
     ning of an X-session or a login session, and all other windows or pro-
     grams are started as clients to the ssh-agent program.  Through use of
     environment variables the agent can be located and automatically used for
     authentication when logging in to other machines using ssh(1).

So what gnome did was include an ssh-agent in the gnome-keyring(-daemon), so it has one interface to manage passwords, ssh keys, etc.  Underneath the hood this is how it works:

1. When Gnome starts the gnome-keyring-daemon (if it is enabled in your conf)
2. The keyring manager starts the ssh-agent component and sets up the SSH_AUTH_SOCK variable, that will redirect ssh to make the queries to that socket
3. The SSH agent automatically loads files in ~/.ssh having names starting with id_rsa or id_dsa or any other keys included by using the ssh-add command
   

That does the job.  If you need to get it working on your Gnome installation follow the instructions here.

I finally got fed up of these messages in my log files (/var/log/messages) and decided to do something about them:

Apr 19 04:14:47 hostname snmpd[3458]: Connection from UDP: [127.0.0.1]:42482
Apr 19 04:14:47 hostname snmpd[3458]: Received SNMP packet(s) from UDP: [127.0.0.1]:42482

After reading, googling around and testing for a while I rounded it the following solution, it should work in any Linux system with net-snmp after some tweaks but out of the box on CentOS, REL, Fedora or any of its relatives:

1. Remove the -a from the snmpd start options or write this in the /etc/sysconfig/snmpd.options file:

OPTIONS=”-Lsd -Lf /dev/null -p /var/run/snmpd.pid”

This should take care of the “Received SNMP” packets line (2nd one).

2. Add dontLogTCPWrappersConnects true at the end of your /etc/snmp/snmpd.conf file, that takes care of the other line:

Apr 19 04:13:47 dcf-is1p snmpd[3458]: Connection from UDP: [127.0.0.1]:48911

According to the man page: This setting disables the log messages for accepted connections. Denied connections will still be logged.”

The problem is that the default settings are to log every connection / request, so what we did was leave the log work only for failed and authenticated attempts

Enjoy readable logs!

It’s really been a while since a sent my last update with pictures of what I’ve done.  I normally try to keep friends and family up to date on what I’ve been doing since I moved to the other side of the Atlantic (to the European side).  So today I fired up picasa to get the web albums up2date and nothing happend.  When I ran it in a shell this came out:

[host]:/home/epablo:\>picasa
/usr/bin/picasa: line 139: 25634 Segmentation fault      “$PIC_BINDIR”/wrapper check_dir.exe.so
/usr/bin/picasa: line 175: 25734 Segmentation fault      “$PIC_BINDIR/wrapper” regedit /E $registry_export HKEY_USERS\\S-1-5-4\\Software\\Google\\Picasa\\Picasa2\\Preferences\\

After googling for I while I didn’t find any reasonable explanation for the error.  I did find a beta (comming from google what could I expect) repository (here are the instructions on how to set it up) and upgraded from picasa-2.7.3736-15 to picasa-3.0.5744-02

It started up, I’ll keep you posted on how it goes with the field try..

After test driving the latest version of VMware Workstation: 6.5.0.  I must say that they fixed most of the small things that made it a pain in the … hard to work with or better described apt for more advanced users.  You get a straight forward RPM installation and everything just works!, you don’t have to patch it anymore.

I did just find a small problem after installing the latest Fedora 9 kernel upgrade to 2.6.27.x, as usual it didn’t start because the new kernel modules have to be built.  The GUI detected the problem, and tried to do it itself but I couldn’t find the reason why so I found two ways to make it work:

• Reinstall the rpm
• Use the following oneline:

TERM=dumb /usr/bin/vmware-modconfig –console –install-all

/etc/init.d/vmware restart

The old vmware-config.pl is gone or maybe just masked but it works as it should.

It’s no secret that I’m a Fedora User and advocate. I’ve been using Red Hat Linux since ‘97 and Fedora since the change. So I just found a js with a counter for the release of Fedora 9 and set it up. There have been many changes over time, some versions I really didn’t like: Red Hat 9 or Fedora 4. I’m not sure of the details of why I just remember upgrading and downgrading a week later. I really have my hopes up for Fedora 9, the actual stable release (8) isn’t one of my favorite upgrades: it fixed some things and broke others. We’ll see what Fedora has in store for us. I’ll be posting a small review once I upgrade and the workarounds I use to get my box working just how I like it.