06 diciembre, 2013

This week I checked how my OCSP bug was going and surprisingly it was closed as fixed. This changeset was submitted two weeks ago to fix the problem and the solution is based on my original idea and patch (only minor differences).

Immediately I compiled again the current JDK 8 and confirmed that my little tests now work smoothly (see the first post of this series for more details). The three scenarios considered by the RFC are now successfully executed with the same java security configuration. It is nice to see that my fix was taken into account. Nevertheless I think that the process is too long and I suspect that the patch was integrated only because it resolves another problem (check the bug comments). But at least the future version of Java will work correctly. Backporting to version 7 is another story, we will see what happens.

Never compromise, not even in the face of Armageddon. (Rorschach — Watchmen)

23 noviembre, 2013

As I commented several times in the blog I have a thing upgrading all my debian boxes. My confidence in this distribution is quite big and problems are rare, even in the case of the testing branch (the one I use). Nevertheless it is a good habit checking the packages that are going to be upgraded (just look over the names). For example mayor version upgrades for the X server or its modules, icedove, gnome core packages or kernel could affect your working productivity, and it is recommended to upgrade them when you have time to fix possible problems. But the summary is that, now, I have only one package that makes my legs shake every time I see its name in the list of packages to upgrade: gnome-shell.

The past Wednesday I run an apt-get update and upgrade and I saw that gnome-shell 3.8 had come to testing (mayor version change, from 3.4 to 3.8 ). I was working and obviously upgrading was risky so I canceled it. But the same day, in the afternoon, I had two or three hours free and I decided to go for it (it was about 5pm but I wanted to jog a bit later). The change from gnome2 to gnome3 had been complicated (see this post I wrote above gnome-shell-extensions at that time) and the transition to current 3.4 version made me again change some extensions. But, you know, it is suppose that now gnome3 is more mature and things should be smoother. That was not the case with my laptop.

During the upgrade the desktop crashed and I upgraded blindly (mental note, gnome-shell should be upgraded using the console -Ctrl+Alt+F1-). After the reboot GDM3 did not start. The horrible message "Oh No! Something has gone wrong" appeared and it was impossible to login. Checking logs (dmesg, /var/log/gdm3,..) was useless, I saw nothing relevant there. After some time I see this bug that was similar but in theory it was fixed in my current version. Nevertheless it gave me the idea to install lightdm (another desktop manager) and, finally, I could enter to a graphical session in my laptop.

To my surprise my gnome-shell desktop was setup by default (all my customizations gone, I suppose that my problem with GDM and all the things I tried to fix the issue forced this situation). So I used gnome-tweak-tool to select the same themes and extensions I had before. But again more surprises, the default dock in gnome-shell-extensions have been removed in 3.7.x, the weather extension I had did not work, and my GTK3 theme and gnome-shell theme had issues (the desktop background did not work, notifications were garbled,...). So nice! Good upgrade! I forgot about jogging, having a comfortable desktop again was going to be long.

The main things I did were the following:

  • The common dock has disappeared so I installed another one. I chose the dash to dock extension which is in the gnome extensions web and worked without problem.

  • The weather extension of Neroth did not work. Neither installing it from the extensions page nor compiling it. But I realized that debian guys had added it to the repository. So it was, at the end, easily installed:

    apt-get install gnome-shell-extension-weather
    
  • Themes were another story. My gtk3 theme had problems and all the others I tried were more or less the same. Finally I decided to just use the default but changing the default blue color for a red one. It could not be so difficult.

    I did the following steps:

    1. Create a new theme directory in the local themes directory for gnome2. My theme will be named AdwaitaRed:

      $ cd ~/.themes
      $ mkdir AdwaitaRed
      $ cd AdwaitaRed
      
    2. Copy the default files in the Adwaita gnome theme and rename the theme to the new name:

      $ cp -r /usr/share/themes/Adwaita/** .
      $ sed -e "s/Adwaita/AdwaitaRed/g" index.theme > index.theme2
      $ mv index.theme2 index.theme
      

      At this moment you can select the new theme with gnome-tweak-tool but it is exactly the same than default Adwaita (but with a different name).

    3. Follow the instructions from tactical vim to uncompress the gresource file (it seems that the default theme instead of using plain files uses an archived one). I copied the script that the site recommends changing some paths:

      $ cat ~/extract.sh 
      #!/bin/bash
      GR_FILE="/home/ricky/.themes/AdwaitaRed/gtk-3.0/gtk.gresource"
      GR_BASEDIR="/org/gnome/adwaita/"
      mkdir /home/ricky/.themes/AdwaitaRed/gtk-3.0/files
      cd /home/ricky/.themes/AdwaitaRed/gtk-3.0/files || exit
      for RSRC in $(gresource list $GR_FILE); do
        RSRC_FILE=$(echo "${RSRC#$GR_BASEDIR}")
        mkdir -p $(dirname "$RSRC_FILE") ||:
        gresource extract "$GR_FILE" "$RSRC" > "$RSRC_FILE"
      done
      

      And executing it the resources were placed in the files directory. After that I deleted the gresource original file.

      $ ~/extract.sh
      $ rm gtk.gresource
      

      Now the references in gtk.css and gtk-dark.css (in gtk-3.0 directory) were changed to link to the dearchived files.

      $ cat gtk.css 
      @import url("files/gtk-main.css");
      $ cat gtk-dark.css 
      @import url("files/gtk-main-dark.css");
      

      Then I changed the gtk-main.css file and all the colors that were blue (a fucking lot of them) were changed to #f43030. Here you can improve the solution, cos there are a lot of different blues (lighter and darker ones), I just changed all of them for the same red color.

      Now if you select AdwaitaRed in the gnome-tweak-tool you have the default Adwaita theme but with red instead of blue (you now, the selections, borders, progress bars and so on).

  • Finally I tried to fix the problem with the gnome-shell theme. I tested the Holo Red and my previous Adwaita X Red but both gave me problems (mainly notifications). So I finally mixed the Adwaita X Red and the default theme.

    1. Copy the default theme in the new custom theme:

      $ cd ~/.themes/AdwaitaRed/
      $ mkdir gnome-shell
      $ cp /usr/share/gnome-shell/theme/** gnome-shell
      
    2. Copy the Adwaita X Red upon default files:

      $ cp ~/.themes/Adwaita\ X\ Red/gnome-shell/** gnome-shell
      
    3. Then I mixed both gnome-shell.css files. It was a nightmare but it seems that now everything works.

With those changes it was around 10pm at night I had wasted all the evening with this task. Besides as soon as I switched off the laptop I realized why GDM crashed in a blinding flash, the problem was for sure that I had customized the greeting screen (just the background picture). Today I have restored the original files of the GDM3 package (those in /etc/gdm3 directory) and GDM3 works again.

In the new version to change the background image you need to modify a css file /usr/share/gnome-shell/theme/gnome-shell.css (I was not dare enough to try another theme). I just changed this property:

#lockDialogGroup {
    background: #2e3436 url(/usr/share/images/desktop-base/magneto-login2.jpg);
    background-repeat: no-repeat;
}

The image should be exactly the resolution of the screen.

I present some screenshots just to show how my desktop looks now.

I do not know, I think this should not be so difficult. It is astonishing for me that gnome changes so many things in each version, extensions are not compatible, themes do not work, previous configurations crashes GDM3,... Nevertheless I have to say that in my desktop box (which uses almost the default gnome configuration) the upgrade was smooth. GDM3 did not crash and my previous configuration was preserve, only some extensions were missing (weather and dock, and the panel settings I use there to auto-hide top panel). So maybe in my laptop I simply had bad luck. I think you start to know me, this entry is mainly for me, the next time I see a major version of gnome-shell in the upgrade list I will come here to revise this information.

Cheerio!

10 noviembre, 2013

Yesterday the version 0.3 of the couchbase-manager was released. As you know it is a little project to manage glassfish sessions inside a couchbase cluster on which I usually spend some time. This version is the first one I feel more or less confortable with it, I think it is starting to be in a mature state. There are mainly two new features in this version: glassfish 4.0 support and, finally, non-sticky configuration is reliable.

As soon as the 0.2 version of my couchbase manager was released the glassfish Oracle group announced the new and bright version 4.0 which, as all of us know, is the reference implementation for JavaEE 7. The couchbase-manager 0.3 works also with glassfish 4.0. I have to admit that the integration was easier than I expected, only some little changes were necessary:

  • Because now the project is mavenized, just setting the new version of packages web-glue and web-core to version 4.0 was enough to start compiling. Although maven has some objections, library dependencies are managed brilliantly.

  • Only one class did not compile. The class was the CouchbaseManagerStrategyBuilder which is in charge of the creation of the manager and the one that the glassfish core uses to inject the manager into the application. It seems that the new glassfish has moved some classes from one package to another. In summary, after changing some few lines, the builder compiled again.

  • In order to manage both versions (glassfish v3 and v4) inside the same project I did some tricks in the maven file (I did not want to separate the code). Now there are two builder classes and two maven profiles, one for v3 and the other for v4, and one class is excluded from compiling depending the profile selected (V3 and V4 maven profiles). It is better explained in the wiki instructions for compiling the project.

  • Finally in the new glassfish 4.0 the manager is defined in another file.

    $ cat META-INF/hk2-locator/default
    [es.rickyepoderi.couchbasemanager.web.CouchbaseManagerStrategyBuilderV4]
    contract={com.sun.enterprise.web.PersistenceStrategyBuilder}
    name=coherence-web
    

    The pity here is that the manager should still be called coherence-web because the reported bug is still present in the new version (nothing has been said about this one).

The second big change is that couchbase server version 2.2.0 fixes the problem about deleting a locked object. That issue forced me to first unlock and then delete the session in previous versions of the manager, and, in a heavy concurrency situation, the two operation technique reported errors. If you check the following bug I opened the issue some time ago and, because couchbase guys did not say anything, I decided to try to fix it by myself. After some hours compiling, checking code, detecting the affected part and fixing it, I realized that the same piece of code had been already patched two months ago. It was a complete waste of time because it was already fixed. I suppose that someone else detected the problem knowing nothing about my bug. I usually work with the community version of couchbase which is one version behind the commercial one. That habit made me fall into that messy situation.

But the result is that finally the manager can delete a session which is locked (passing the cas value). I have tested for a long time the non-sticky configuration and now no concurrency problems are detected. It can be said that now non-sticky solution is reliable.

Nevertheless the new couchbase version has also fixed the touch method. Now when a session is locked touch method results into an error (previously a locked object can be touched without problem). Because there are no unlockAndTouch or similar method in the API I decided to always save the session (cas in non-sticky, set in sticky). It is not a problem cos, after I realized that an attribute can be modified without being put again in the session, the cases when a session was not dirty, and can be touched instead of saved, were really a very little percentage. As a result the previous manager property maxTimeNotSaving has been removed (that property controlled when to save a session which has been only touched for a long time).

Finally I am going to show some times (in ms) of the manager for both configurations. As in the previous entries the configuration is two glassfish v3 in a KVM cluster against a single couchbase installed in my physical laptop. The manager is tested with different session sizes (50, 200, 2000 and 4000 bytes). More or less the numbers are stable and similar to the previous versions except the delete operation, which is slightly slower.

Sticky Configuration
Non-Sticky Configuration

So the summary is that the new version 0.3 of the couchbase-manager is the first one without known problems (I am lying, there is still the LDAP realm problem because of a glassfish bug, but it is a very specific problem). I have more ideas to improve the solution (mainly dealing with attributes as separate objects in order to not save the whole session all the time) but I do not really know when I have the time and the mood to start with such a big change. Just one more comment, in my tests (performance tests mainly) I see that the couchbase server is highly intensive in disk writing (my laptop disk, which is also encrypted, was at 95-100% of utilization rate during tests). As I said several times, in my specific solution persistence to disk is not completely necessary, I think that replicas are enough security for a cache system. But couchbase buckets cannot disable disk persistence (see this forum entry or this another one). I hope that someday this feature was configurable exactly as the replica behavior.

Enjoy version 0.3!