I didn’t really need networking setup at all and just wanted to skip waiting for the network to be configured. In order to do this you just need to edit the file /etc/init/failsafe.conf. In that file is where it sleeps for several minutes waiting for the network to come up. All I did was:

sudo vim /etc/init/failsafe.conf

I changed the first sleep command to

sleep 5

and then commented out the following lines:

$PLYMOUTH message --text="Waiting for network configuration..." || :
sleep 40
 
$PLYMOUTH message --text="Waiting up to 60 more seconds for network configuration..." || :
sleep 59

Just place a ‘#’ character at the beginning of each of those lines. Now it will just wait 5 seconds and then continue on.

To my surprise, the network was actually working just fine even though the script thinks it is not.

Just a note, do NOT remove the failsafe.conf file, otherwise it will hang the boot process indefinitely waiting for the network to be “configured.”

Because of the frustration with recent versions of Ubuntu I have started to test out other desktop distributions for my laptop and desktop machines. I first tried using Linux Mint with it’s Cinnamon UI, however I quickly found that Cinnamon was not very mature and didn’t suit my tastes. I guess it’s just like slapping lipstick on a pig, and not very good lipstick either.

After my trials with Linux Mint I almost decided to try out openSuSE. The funny thing is, I work at Novell and work with SuSE Linux Enterprise Server all day and have obviously tried openSuSE before. However, it left a very bad taste in my mouth and several of my colleagues use openSuSE and gripe about it fairly often, so I decided to stay away for now.

That’s when I decided to try out Fedora. I had used fedora before at college (different class) and tested it out briefly on an old laptop I had. Neither of these experiences left a great experience in my mind, but it wasn’t terrible either, the reason Fedora didn’t work so well on my laptop wasn’t really Fedora’s fault. So, anyway, I decided to try out Fedora on my laptop and am absolutely loving it. I love the fact that they have the most recent versions of tons of software. One thing I always loved in Ubuntu was dpkg/apt-get (package management) and the bash completion support…that feature is SERIOUSLY lacking in SuSE and it bugs the crap out of me. However, Fedora’s yum package manager tool is wonderful.

Now, getting to the point where this affects server distributions. Because I have had such an awesome experience with Fedora I am now ready and excited to try out CentOS on my next server that I install. It may still take some getting used to but I know that CentOS/RedHat have a great reputation and I have somewhat of an idea of what to expect.

So everybody that develops a server distribution of Linux, take note and make sure your desktop experience really shines and is delightful to use for engineers that may end up using your server distribution, since we are the ones that will be making the decisions as to what distribution to go with.

export JAVA_BIN_DIR=/usr/java/jdk1.x.x_xx/bin # replace 1.x.x_xx with your installed version
cd ${JAVA_BIN_DIR}
for exe in *; do
sudo update-alternatives --install "/usr/bin/${exe}" "${exe}" "${JAVA_BIN_DIR}/${exe}" 1
sudo update-alternatives --set ${exe} ${JAVA_BIN_DIR}/${exe}
done

And thats it, test it out by running java -version.

Also, I had a problem where I installed LibreOffice which installed the OpenJDK RPM and it overrode the Oracle java version I had installed, to fix that I just re-ran the above script and it reset it to use the correct java version.

The trouble I had getting RHEL6 to install as a paravirtualized VM on XEN was the vm-install process was trying to boot a kernel from the installation media that didn’t exist. I would get errors that the path /images/xen/vmlinuz didn’t exist and even when I fixed that after rebooting it would fail because it couldn’t find the correct kernel. To get around this just takes a few little steps.

First, you need to copy the installation media to a web server and make a symbolic link from /images/pxeboot/ to /images/xen and so when XEN launches the installation it will pick up the pxeboot vmlinuz image which actually works just fine.

The next step is at the end of the installation don’t reboot. You need to go to the console on the VM. With the gui vm-install you can just hit the menu item ‘Send Key’->’Ctrl-Alt-F2′. Now you need to go to the /mnt/sysimage/boot directory. Here is where your dom0 xen will look for a kernel to use to boot. It will look for a file called vmlinuz-xen or vmlinuz-xenpae. Look for the default vmlinuz (mine was called vmlinuz-2.6.32-71.el6.i686). Now just make a symbolic link from that file to vmlinuz-xen. It will reboot and find the kernel and everything will work just fine even though there isn’t a specific xen kernel because of (I think) the pv drivers Red Hat decided to keep in there anyway (even though they dropped support for RHEL as a XEN host).

You will need to keep the vmlinuz-xen symbolic link up to date every time there is a new kernel installed, otherwise you will keep running on the original kernel (or the link might get broken if the old version is removed).

There are a couple of ways to get around this and they are documented here http://wiki.python.org/jython/NewSocketModule#SSLSupport. However, I didn’t like any of those approaches.

The first option requires messing with your certificate store in the JVM which means all Java processes doing anything will have your certificate added. This may or may not be what you want, but if you go to another machine or use a different JVM you will lose the ability to connect to your SSL host again.

Option 2, creating your own Security Provider looked a little more appealing because I don’t have to worry about importing each certificate and could enable this at runtime. However, it has the drawback of having to be compiled outside of Jython, and has to be put on the class path. Again, this makes it a little less portable (but not too bad). It also has the affect of trusting all certificates for every single SSL connection made, which is good because it matches up to what Python does but what if you want to only trust invalid certificates in certain parts of your code?

I started digging and came up with a way that would let me trust all certificates, be written completely in Jython, and have the ability to dynamically switch between trusting all certificates or not.

# Check if running in Jython
if 'java' in sys.platform:
    from javax.net.ssl import TrustManager, X509TrustManager
    from jarray import array
    from javax.net.ssl import SSLContext
    class TrustAllX509TrustManager(X509TrustManager):
        '''Define a custom TrustManager which will blindly accept all certificates'''
 
            def checkClientTrusted(self, chain, auth):
                pass
 
            def checkServerTrusted(self, chain, auth):
                pass
 
            def getAcceptedIssuers(self):
                return None
    # Create a static reference to an SSLContext which will use
    # our custom TrustManager
    trust_managers = array([TrustAllX509TrustManager()], TrustManager)
    TRUST_ALL_CONTEXT = SSLContext.getInstance("SSL")
    TRUST_ALL_CONTEXT.init(None, trust_managers, None)
    # Keep a static reference to the JVM's default SSLContext for restoring
    # at a later time
    DEFAULT_CONTEXT = SSLContext.getDefault()
 
def trust_all_certificates(f):
    '''Decorator function that will make it so the context of the decorated method
    will run with our TrustManager that accepts all certificates'''
    def wrapped(*args, **kwargs):
        # Only do this if running under Jython
        if 'java' in sys.platform:
            from javax.net.ssl import SSLContext
            SSLContext.setDefault(TRUST_ALL_CONTEXT)
            try:
                res = f(*args, **kwargs)
                return res
            finally:
                SSLContext.setDefault(DEFAULT_CONTEXT)
        else:
            return f(*args, **kwargs)
    return wrapped

Thats it. Now I can do things like:

@trust_all_certificates
def connect_to_untrusted_host(host):
        conn = httplib.HTTPSConnection(host)
        conn.request('GET', '/index.html')
        response = conn.getresponse()

And the connection will succeed. If I have another method that is not decorated then it will automatically verify the certificates validity.

Note that this decorator is not thread safe. Setting the SSLContext default is a global operation, so if another thread is running it could reset the SSLContext to the default before another method tries to make an SSL connection.

You can also use this without the decorator function. Just use the code prior to the decorator and set the SSLContext default wherever you need to.

If you happen to also need to verify the hostname of a certificate, which is the case if you use an HttpsURLConnection, then you will also need to create a HostnameVerifier. You can do this as follows:

from javax.net.ssl import HostnameVerifier, HttpsURLConnection
class AllHostsVerifier(HostnameVerifier):
    def verify(self, urlHostname, session):
        return True
HttpsURLConnection.setDefaultHostnameVerifier(AllHostsVerifier())

Hope that helps. It’s nice to have a pure Jython implementation of this and have it be transportable.

The only problem I have had is that Tomboy Notes on one of my Windows machines would never open. It would start and I would see the icon in the notification area but then it would disappear and I couldn’t ever do anything. Today I figured out how to get around it.

To fix this I just went to the Tomboy.exe file and went to Properties -> Compatibility and set it to run in compatibility mode for Windows XP SP3. Now everything is working great!

The problem turned out to be with autofs. We were using autofs to keep the storage mounted in our little cluster of machines. The weird thing is that it will not show the directory it is mounting when doing an ls. I do ls /auto/ and I see nothing. I do ls /auto/home and voila, I see a bunch of files. So, I just had to turn off autofs and the symbolic link worked just like it should.

I had some problems with audio though. I tried several solutions I found on a forum here: http://ubuntuforums.org/showthread.php?t=346676 and http://ubuntuforums.org/showthread.php?t=1043568 but I think the thing that really made it work was that for some reason I was not in a group that would allow access to sound devices. The page here https://wiki.ubuntu.com/DebuggingSoundProblems said to make sure you have permissions for it…I figured this would be the last thing that would work since I was the user that installed the system, well, I guess I was wrong, the little checkbox wasn’t checked, I checked it and restarted and it work, who would have thought?

Now I just need to get bluetooth working…wasn’t seeing my phone…

I found these tips on the Novell Cool Solutions page. One from http://www.novell.com/communities/node/1516/imaging-sled-10-sp1-workstation and another from http://www.novell.com/communities/node/5789/automatic-network-configuration-and-edirectory-configuration-bootable-vmware-images.

There are just two general steps that need to take place. First, make it so GRUB boots using the device name and not the device ID. To do this:

1. Open Yast
2. Navigate to System -> Partitioner
3. For each partition that will be mounted click Edit, Fstab Options, and select Device name rather than Device ID
4. Apply those settings
5. Now open Yast -> System -> Bootloader
6. For each entry click edit and for the root device select the proper device name
7. Apply those settings and you are done

The second issue has to do with the device ID of the network card changing and so it is not configured for DHCP on boot. To make all your network interfaces configure automatically with DHCP on boot you need to be able to generate ifcfg-eth-id network configuration files for the interfaces on boot. To do this

1. Download this buildeth0 script from (This was taken from a set of scripts on the second Novell link above)
   1. If you are running SLES/SLED 11 then download this script and rename it to buildeth0
2. Copy the script buildeth0 to /etc/init.d/. Be sure to chmod 755 the script so it will execute.
3. Now, add the script to the default run-levels rc3 and rc5 by running “chkconfig -a buildeth0″

This script requires that the persistent names are enforced and generated when your machine boots. This is already on by default in SLES/SLED. When the machine boots it will check all the devices connected and create persistent names for any ethernet device in /etc/udev/rules.d/30-net_persistent_names.rules. The script will check that file for any entries. It will then check to see if each of those entries have configuration information setup in /etc/sysconfig/network/ifcfg-eth-id-… if not it will generate that file automatically and configure the interface with DHCP. When the network is setup it will see the configuration there and configure the interface with DHCP.

To prepare for taking an image you should remove all the configuration information already setup for your machine so that when the new device boots it doesn’t wait for non-existing interfaces to be set up.

1. rm /etc/sysconfig/network/ifcfg-eth-id*
2. Edit /etc/udev/rules.d/30-net_persistent_names.rules and remove any SUBSYSTEM==”net” lines. (Don’t just comment them out)

That’s it, just shutdown and take a snapshot/image of the machine.

svn copy https://your.svn.server/svn/location/trunk https://your.svn.server/svn/location/branches/branch_name -m "commit message"

All the work is done on the server. No mess locally and super quick…now I just need to figure out how to merge changes between branches easily