Draft Thoughts from Pedro Gómez: From time to time and whenever something worthy of sharing comes to mind I´ll place it here.

[Read More]

I was listening to a podcast of the uptime institute yesterday. Amy Wohl described her thoughts on what Companies should do in this time of crisis with regards to IT. She advised to start using virtualization "if you haven't started already". Virtualization has proven to be a good solution to make better use of compute resources, that are otherwise idling in the datacenter. There is an old saying in my home town about the old hens: They eat and drink the same amount than the young ones, but do not produce many eggs... .

An interesting point Amy,but more than the point, I want to comment on the timing "....if you haven't started already..."

One of the thoughts I would have being a Sun customer that has not started already with Virtualization is related to the risks involved.

1. Why would I, in time of crisis take on a project that could potentially harm my existing implementations? (when you virtualize you tend to put more apps in one server, so if things are not properly planned and designed, we could increase the likelihood of failure instead of the benefits we are looking for).
   
2. Why would I look to add a new vendor in this time of crisis (new to the customer that is) ?
3. Could I start working on virtualization with what I already have in place?

I'd say these are legitimate concerns for our customers. Times of crisis, you want to adjust but you wouldn't want to jeopardize operations by introducing too many variants in the data center. So how do we move forward without sinking the boat in the attempt?

That is where I truly believe we have a unique positioning for these times of crisis. I wrote the other day a little bit about what have we done as a company in virtualization. Our  customers who have not started a virtualization approach because of the risks involved, have a relatively easy way to start. Just learn (or ask us about)  how to  turn the virtualization features that are already embedded in their Sun environments, ah by they way, there are no licenses fees attached !

Every Solaris 10 server that is running out comes with the features of Solaris Containers. Sparc, X86. You can virtualize dozens, hundreds if you want without having to pay one additional cent. And it is the same Solaris...Learning curve? very small because is the same Solaris

Every CMT base server you have comes with LDOMS, a hypervisor that allows you to split the server into different Solaris or Linux instances, also without a license attached !.

So there you have a couple of ways to work through the crisis by reducing you power/cooling bill and your rack space without having to learn how to dance with a new technology/vendor in times of crisis. We are talking about Solaris so you know how the OS behaves in peak times and under stress , so you already know how good Solaris is "in time of crisis".

I must admit that am a little behind with regards to the use of video, flash demos and so on for demonstration purposes. Is not that I was not exposed early to it because I remember that screen videos where practically the primary training tool used by the consultant team in an SAP implementation that I participated in. That was over 10 years ago.

The thing is that I have not decided to embrace the technology, mainly because of those little things. Every time I wanted to find a screen video recorder I found one with glitches or conditions (30 day trial, etc,), so I stopped and postponed...

But during these last couple of weeks I started visiting the idea again. I thought of a few premises of interest:

• Everything Free . Open Source, or freeware
• Easy to use
• Avi Files are expensive in terms of disc space, so I want to be able to see the final product in a reduced footprint, like the one flash generates.
• Web accessible off course

A few days ago I  decided to give it another try and went to Mr Google to find out about freely available options.

I found a couple of good things

Camstudio.org . Allows me to record a windows, audio, full screen or a piece of the screen and turn it into an avi file. It also allows me to pause the recording and resume easily whenever am ready.It even comes with the option con convert from avi to flash, something that other software houses add for a fee.

Free Video to Flash Converter (3.51)  ( http://www.dvdvideosoft.com/free-dvd-video-software.htm) to change from avi to flash format. Even though camstudio has the option, I find this one a bit more elegant since it lets you pickup the style of player and it creates a neater set of files (flv, xml,html) with the final product.

I also found an utility that zooms in the screen around the position of the cursor. It is called zoomit.

With those 3 tools I am ready to work on my experiment. The demos I am usually working on these days are basically shell-based. So I want to be able to record the shell commands, but the commands are quite dry, meaning I can't see any thought process on what am I intending to do, what happens next , what if, and so on.

Usually when am working on something worth taking notes, I open up a notepad application (notepad or wordpad are preferrable because they are very lightweight) and record what am doing, what am thinking , errors that I find, web links of help etc... So I thougth, why not put a couple of screens together and record the thought process and the demo commands side by side, that way I have the notes and the actions together. I can put them later on whatever the repository might be (youtube, ssc-latinamerica.com, etc) .

This is obviously very,very rudimentary way of creating demos, but is also very simple. I don't need to go out of my way to create a special environment or go into a "recording studio" to record stuff, I basically hit the record button and work. I wil be doing a few of these "Flash with Notes demos" as written records of shell demoable features for whatever topic could be of interest.
I have a few samples of these casts in the new  portal for the SSC Fort Lauderdale

La instalación del Portal Liferay en el Sun Solution Center ha sido una experiencia muy agradable desde el punto de vista de configuración, funcionalidad e instalación. Los detalles:

Obtuve el “bundle” para liferay 5.1.2 tomcat 6.0 del website www.liferay.com . La primera instalación la hice en una máquina virtual(box) ubuntu en mi laptop. La instalación es extremadamente sencilla. Solo se requiere descomprimir el archivo , y ejecutar el script startup.sh. A partir de alli, el portal funciona, inicialmente en la direccion http://localhost:8080

Con la promesa de la portabilidad de Java, (write once , run anywhere) , el mismo archivo bundle utilizado en la máquina virtual , lo copié en una zona de una servidor x2100 con Solaris 10 update 4. Mismo procedimiento de descomprimir y startup.sh. Mismo resultado, http://localhost:8080 y el portal activado.

Inicialmente el portal ejecuta con una base de datos incluida (hysql) , totalmente funcional pero no necesariamente lo que queremos para un ambiente de producción. Lo digo porque en una oportunidad, resetenando el servidor, la data pareció perderse. En lugar de utilizar esta base de datos, instalamos mysql 5.1.23 . El cambio esta muy bien documentado tanto en la guía rápida como en la de administración. Liferay solo pide que crees una base de datos nueva de nombre lportal y el script (startup.sh) se encarga de inicializarla la primera vez que se levanta la aplicación.

Algo que terminó siendo importante fue la versión del jre utilizada . Originalmente el servidor en Solaris 10 tenía la version 1.5. Al momento de colocar el servidor detrás de un firewall , en NAT 1:1, se presentaron problemas de lentitud en el despliegue de las páginas. Actualicé la versión a la 1.6 y los problemas desaparecieron.

Otro de los cambios que probé con éxito fue el de mantener la misma base de datos y cambiar el servidor de aplicaciones Asi pude comprobar que con muy pocas modificaciones, es sencillo cambiar el servidor de aplicaciones en caso de que surja la necesidad. En el bundle vienen las alternativas de tomcat, tomcat+jboss , glassfish, entre otros.

La facilidad de uso y configuración del portal es impresionante. Basado en el esquema de portlets, lidereay me permitió tener un portal operativo con solo pocas horas de trabajo y sin ninguna experiencia previa en la aplicación.

El resultado actual se puede ver aqui: http://portal.la-solutioncenter.com

 

This is a follow up exercise of the Containers on the Move post. This is the scenario for which this test applies:

A customer has some containers running on a server as application servers. These containers are in the production environment so halting and rebooting is undesirable. The containers where created on Solaris 10 update 3, customized to run specific applications and then a backup of the containers was performed.

We would like to test the possibility to move a container to another server with Solaris 10 update 6 without halting it. We are interested in making sure the packages and patches remain leveled as we move them.

An approach to do this is to create a "surrogate" container in the same server with similar characteristics to the zone we are interested in, halt it and detach it. Once the detached is performed, a file called SUNWdetached.xml is created. This file contains all the packages and patches pertinent to the zone. It also contains the configuration of the detached zone, which is what we are interested in.

Our test gear is the following:

We want to move the spar zone, and we will use the bridge zone as the surrogate.

Let's asume the following tasks related to the creation of the zones where performed in the past. We created both zones

root@anaco # zonecfg -z bridge

bridge: No such zone configured

Use 'create' to begin configuring a new zone.

zonecfg:bridge> create

zonecfg:bridge> set zonepath=/zones/roots/bridge

zonecfg:bridge> add net

zonecfg:bridge:net> set physical=ce2

zonecfg:bridge:net> set address=10.10.100.110

zonecfg:bridge:net> end

zonecfg:bridge> verify

zonecfg:bridge> commit

zonecfg:bridge> exit

root@anaco # zonecfg -z bridge info

zonename: bridge

zonepath: /zones/roots/bridge

autoboot: false

pool:

limitpriv:

inherit-pkg-dir:

        dir: /lib

inherit-pkg-dir:

        dir: /platform

inherit-pkg-dir:

        dir: /sbin

inherit-pkg-dir:

        dir: /usr

net:

        address: 10.10.100.110

        physical: ce2

root@anaco # zoneadm -z bridge install

Preparing to install zone <bridge>.

Creating list of files to copy from the global zone.

And clone the bridge zone to create the spar zone. This link has a clean how-to-guide for cloning

1.- We halt the Bridge zone

root@anaco # zoneadm -z bridge halt

2.- Export Bridge zone configuration

root@anaco # zonecfg -z bridge export > /tmp/spar.cfg

3.- Change parameters of new zone (hostname and IP address)

root@anaco # vi /tmp/spar.cfg

root@anaco # more /tmp/spar.cfg

create -b

set zonepath=/zones/roots/spar

set autoboot=false

add inherit-pkg-dir

set dir=/lib

end

add inherit-pkg-dir

set dir=/platform

end

add inherit-pkg-dir

set dir=/sbin

end

add inherit-pkg-dir

set dir=/usr

end

add net

set address=10.10.100.111

set physical=ce2

end

4.- Create new zone from configuration file spar.cfg

root@anaco # zonecfg -z spar -f /tmp/spar.cfg

5.- Clone Bridge zone

root@anaco # zoneadm -z spar clone bridge

Cloning zonepath /zones/roots/bridge...

root@anaco # zoneadm list -iv

  ID NAME             STATUS         PATH

   0 global           running        /

   2 dns-backup       running        /zones/roots/dns-backup

   - bridge           installed      /zones/roots/bridge

   - spar             installed      /zones/roots/spar

root@anaco # zoneadm -z spar boot

Asuming we are still in the past, we backed up the zone spar without detaching it

root@anaco # zoneadm -z spar halt

1.- Create a tar file of the zone spar

root@anaco # cd /zones/roots/spar

root@anaco # tar cvf /tmp/spar.tar *

root@anaco # ls -lh /tmp/spar.tar

-rw-r--r--   1 root     root        202M Dec 23 08:05 /tmp/spar.tar

The resultant spar.tar is then shipped (scp, ftp, nfs  or any other way) to the target server T5520. I did it with ftp

The following steps are performed in the present. By now, the spar zone has been running for a while and it is in the production environment so we don't want to reboot it again, something we would have to do if we were to detach it. We will use instead the bridge zone, detaching it and borrowing its detached file to recreate the spar zone in the target server.

root@anaco # zoneadm -z bridge detach

root@anaco # cd /zones/roots/bridge
root@anaco # ls
dev               root              SUNWdetached.xml

I ship (ftp) the generated SUNWdetached.xml file to the T5220


Now in the target server (T5220) , lets create the target zone,

First untar the spar.tar files in its new home

root@t5220 # mkdir -m 700 -p /zones/spar

root@t5220 # cd /zones/spar

root@t5220 # mv /tmp/spar.tar .

root@t5220 # tar xvf spar.tar

root@t5220 # zonecfg -z spar

spar: No such zone configured

Use 'create' to begin configuring a new zone.

zonecfg:spar> create -a /zones/spar

invalid path to detached zone

zonecfg:spar> exit

root@t5220 # pwd

/zones/spar

As expected zoneadm didn't like it ,because it didn't have the SUNWdetached.xml file as this tar directory was not detached. We now make a copy of the /tmp/SUNWdetached.xml file into the /zones/spar directory, and modify the file (changed "bridge" by "spar" and "10.10.100.110" by "10.10.100.111")

root@t5220 # cp /tmp/SUNWdetached.xml /zones/spar

root@t5220 # ls

dev               lu                root              SUNWdetached.xml

root@t5220 # vi SUNWdetached.xml

"SUNWdetached.xml" 2573 lines, 114051 characters

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE zone PUBLIC "-//Sun Microsystems Inc//DTD Zones//EN" "file:///usr/share/lib/xml/dtd/zonecfg.dtd.1">

<!--

    DO NOT EDIT THIS FILE.  Use zonecfg(1M) and zoneadm(1M) attach.

-->

<zone name="spar" zonepath="/zones/roots/spar" autoboot="false">

  <inherited-pkg-dir directory="/lib"/>

  <inherited-pkg-dir directory="/platform"/>

  <inherited-pkg-dir directory="/sbin"/>

  <inherited-pkg-dir directory="/usr"/>

  <network address="10.10.100.111" physical="ce2"/>

  <package name="SUNWocfd" version="11.10.0,REV=2005.01.21.15.53"/>

  <package name="SUNWasu" version="8.2,REV=2006.08.16.09.11"/>

  <package name="SUNWcsr" version="11.10.0,REV=2005.01.21.15.53"/>

....(rest of output ommited)...

Now, let's try again creating the zone.

root@t5220 # zonecfg -z spar

spar: No such zone configured

Use 'create' to begin configuring a new zone.

zonecfg:spar> create -a /zones/spar

zonecfg:spar> exit

root@t5220 #

This time it worked.!!!. Now going for the attach and update

zonecfg:spar> create -a /zones/spar

zonecfg:spar> exit

root@t5220 # zoneadm -z spar attach -u

zoneadm: zone 'spar': ERROR: attempt to downgrade package SUNWglh, the source had patch 120812-27 but this system only has 120812-25

At first I thought this was the bug I saw before in the first post but the 120812 patch is an OpenGL patch. 120812 doesn't seem to be related to this bug because even if I put the 120812 in the bad_patches file, the result is the same. 

To solve the problem I downloaded the latest patch, 120812-28 and installed it in the T5220

root@t5220 # patchadd -d 120812-28

After installig the patch, we try the attach again

root@t5220 # zoneadm -z spar attach -u

Getting the list of files to remove

Removing 1008 files

Remove 576 of 576 packages

Installing 2659 files

Add 714 of 714 packages

Updating editable files

The file </var/sadm/system/logs/update_log> within the zone contains a log of the zone update.

We can verify that the zone is installed..

root@t5220 # zoneadm list -iv

  ID NAME             STATUS     PATH                           BRAND    IP

   0 global           running    /                              native   shared

  11 jboss            running    /zones/jboss                   native   shared

   - spar             installed  /zones/spar                    native   shared

Now , we adjust the NIC to e1000g1 to adapt it for the T5220

root@t5220 # zonecfg -z spar info

zonename: spar

zonepath: /zones/spar

brand: native

autoboot: false

bootargs:

pool:

limitpriv:

scheduling-class:

ip-type: shared

inherit-pkg-dir:

        dir: /lib

inherit-pkg-dir:

        dir: /platform

inherit-pkg-dir:

        dir: /sbin

inherit-pkg-dir:

        dir: /usr

net:

        address: 10.10.100.111

        physical: ce2

        defrouter not specified

root@t5220 #

root@t5220 # zonecfg -z spar

zonecfg:spar> select net address=10.10.100.111

zonecfg:spar:net> set physical=e1000g1

zonecfg:spar:net> end

zonecfg:spar> verify

zonecfg:spar> commit

zonecfg:spar> exit

root@t5220 # ifconfig -a

lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1

        inet 127.0.0.1 netmask ff000000

lo0:1: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1

        zone jboss

        inet 127.0.0.1 netmask ff000000

e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2

        inet 10.10.10.228 netmask ffffff00 broadcast 10.10.10.255

        ether 0:14:4f:d5:7:a

e1000g1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3

        inet 10.10.100.228 netmask ffffff00 broadcast 10.10.100.255

        ether 0:14:4f:d5:7:b

e1000g1:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3

        zone jboss

        inet 10.10.100.181 netmask ffffff00 broadcast 10.10.100.255

root@t5220 # zoneadm -z spar boot

root@t5220 # zlogin spar

[Connected to zone 'spar' pts/3]

Last login: Tue Dec 23 04:57:12 on pts/4

Sun Microsystems Inc.   SunOS 5.10      Generic January 2005

You have mail.

#

#

# ping 10.10.100.254

10.10.100.254 is alive

# uname -a

SunOS spar 5.10 Generic_137137-09 sun4v sparc SUNW,SPARC-Enterprise-T5220

The new Solaris update 6 has implemented a potentially powerful feature. "Update on Attach". The attaching and detaching of zones was introduced in Update 3 . The initial scope allowed first to move a container from one place to another inside the same server, something useful for those who started the container on a local file and wanted to move it to a file sytem or raw device, always inside the server. Then it seems to have evolved to allow moving the container from one server to another. Here the disclaimer was that the two servers needed to be similar architectures (say from one T2000 to another T2000. This paper explains nicely how to move a container from one place to the other)

With the new update on attach option, we can now move a container that was created in say a v490 to a T5220. Solaris takes into consideration the packages and patches installed in the source system and the ones needed in the target system and updates them as it builds the new container, nice.

The process is very simple in general

1. In the source server (the one with the container we want to move), Halt the zone
2. Detach the zone
   
3. Tar , zip or pax the container and ship it to the new target server
   
4. In the target server (the new home of the container ), untar, unzip, or unpax the container
   
5. Create a container , attach it, and and tell Solaris to clean it up ( update it )
   
6. Manually reconfigure things like the NIC
   

We started to test this concept in the lab with an approach that resembles that one of those who open up a new toy and start playing with it without reading the instructions. That way we learned that the "detach" option does not exist in update 1 nor 2. If we want to move the containers, they must be in Update 3 and up

We ran the experiment with a couple of servers

M5000 , Solaris 10, U5 as the source server for the container

T5220 , Solaris 10 U6 as the target server.

In the source system , this is the container we wanted to move.:

root@m5000-dom0 # zonecfg -z jboss info

zonename: jboss

zonepath: /zones/jboss

brand: native

autoboot: false

bootargs:

pool:

limitpriv:

scheduling-class:

ip-type: shared

inherit-pkg-dir:

        dir: /lib

inherit-pkg-dir:

        dir: /platform

inherit-pkg-dir:

        dir: /sbin

inherit-pkg-dir:

        dir: /usr

net:

        address: 10.10.100.165

        physical: bge1

root@m5000-dom0 #

Step 1. Halt the zone

root@m5000-dom0 #zoneadm -z jboss halt

root@m5000-dom0 #

Step 2. Detach the zone from the source server

root@m5000-dom0 # zoneadm -z jboss detach

This step creates an  xml file SUNWdetached.xml with the details of the zone, packages and patches.

Step 3. Tar, Zip or Pax the container.

We followed the model of the how-to-guide paper mentioned before.

root@m5000-dom0 # pax -w@f /tmp/jboss.pax -p e * 

Step 4. Move the compress file to the target system and place the contents in the target zonepath of the new zone.

We used ftp to transfer the pax file (jboss.pax) from the M5000 server to the /tmp dir in the T5220. (The ftp command not shown).

root@t5220 # mkdir -m 700 -p /zones/jboss

root@t5220 # cd /zones/jboss

root@t5220 # ls

root@t5220 # pax -r@f /tmp/jboss.pax -p e

root@t5220 # ls

dev               root              SUNWdetached.xml

Step 5. Create the new container, Attach it and Update it.

root@t5220 # zonecfg -z jboss

jboss: No such zone configured

Use 'create' to begin configuring a new zone.

zonecfg:jboss> create -a /zones/jboss

zonecfg:jboss> exit

root@t5220 # zoneadm -z jboss attach -u

In this step, we hit a bug :

"

Document ID:    6743776
Title:    zone update on attach should ignore all "special" patches
Synopsis: zone update on attach should ignore all "special" patches

..."special" patches are not released, so customer
can never get them.  They only show up on a
customer system as patch metadata.  When migrating
a zone, if the source had the special patch, but
the target is at a later release, there is no way
to bring the target up to sync with the source system
since the patch is not available and these patches
are never obsoleted.

..."

The workaround for it  is to add the list of patches indicated in the Document ID to the file /usr/lib/brand/native/bad_patches . I only had to add the following ones

125097
128011
128010

After that, the command of attach works nicely with the following output

Getting the list of files to remove

Removing 1052 files

Remove 650 of 650 packages

Installing 2656 files

Add 642 of 642 packages

Installation of these packages generated warnings: SUNWsmbar

Updating editable files

The file </var/sadm/system/logs/update_log> within the zone contains a log of the zone 

update.

root@t5220 # zoneadm -z jboss boot

root@t5220 # zlogin -C jboss

[Connected to zone 'jboss' console]

Hostname: jboss 

Step 6. Adjust Networking

Now, the original container was hosted in an M5000 using bge1 as the physical network interface. Since the T5220 has E1000 Nics, the zone didn't have networking when first booted. To adjust the nic we do the following: (Note that we decided to change the IP from 10.10.100.165 to 10.10.100.181

root@t5220 # zonecfg -z jboss

zonecfg:jboss> select net address=10.10.100.165

zonecfg:jboss:net> set physical=e1000g1

zonecfg:jboss:net> set address=10.10.100.181

zonecfg:jboss:net> end

zonecfg:jboss> verify

zonecfg:jboss> commit

zonecfg:jboss> exit

and reboot the zone to take the new values in effect

root@t5220 # zoneadm -z jboss reboot

This week we had an urgent request to install (SSC Fort Lauderdale) a configuration for a customer interested in evaluating a java application running on the weblogic server and communicating to an oracle database server. The requested setup was:

1. Solaris 10 Sparc 5/08
   
2. Oracle 10g R2
3. Weblogic Server 9.2
   

We had done 1 and 2 in several opportunities so there was nothing to fear there. #3 was a first for me, but I had a partner for this task, Giovanni Gomez, imported from Colombia .

We had no trouble with the database server. Oracle 10G R2 is quite easy to install and easy to launch too.

Weblogic was a different story. We downloaded the 9.2 server from the bea websiste . Giovanni installed it and there were no error messages here. We did not run the quickstart program .We should have ran it then to validate that the app server domains were going to launch (or not).

Later on when the application engineer (from an ISV) came to install the application, we noticed that weblogic was throwing an error:

<Jul 30, 2008 9:59:34 PM EDT> <Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason:

There are 1 nested errors:

weblogic.management.ManagementException: [Management:141266]Parsing Failure in config.xml: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID = 4418622981026545151, local class serialVersionUID = -9120448754896609940
        at weblogic.management.provider.internal.RuntimeAccessImpl.<init>(RuntimeAccessImpl.java:122)
        at weblogic.management.provider.internal.RuntimeAccessService.start(RuntimeAccessService.java:38)
        at weblogic.t3.srvr.ServerServicesManager.startService(ServerServicesManager.java:374)
        at weblogic.t3.srvr.ServerServicesManager.startInStandbyState(ServerServicesManager.java:125)
        at weblogic.t3.srvr.T3Srvr.initializeStandby(T3Srvr.java:630)
        at weblogic.t3.srvr.T3Srvr.startup(T3Srvr.java:402)
        at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:361)
        at weblogic.Server.main(Server.java:67)
Caused by: java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID = 4418622981026545151, local class serialVersionUID = -9120448754896609940
........

This was nothing fun to find since we had a very limited window for the tests. A couple of googles-searches (actually a lot of them ) and we found a lead on the problem

http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=76aa2a510fc5edffffffffe6e9633a900cef5?bug_id=6267224

The root cause of the bug

"This issue is a result of the migration of javax.xml.namespace.QName from J2EE1.4 to J2SE5.0;  "

We tried several alternatives/workarounds :

1. Someone mentioned that a similar problem was solved using a JDK version 1.5.0_6 , we had 1.5.0_14. We tried this. Didn't work.
2. We tried switching the JVM with JRockit. Didn't work
3. We tried adding the following
   

   -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 

   to the JAVA_OPTIONS variable in here  /usr/local/bea/weblogic92/samples/domains/wl_server/bin/setDomainEnv.sh . This worked initially for the sample domain wl_server. For some reason I don't know yet, it stopped working after a while.
   
4. At this point, I sent an internal mail to an alias with little hope of getting an answer the same day (the time was 9:00pm-10:00pm EST). In my frustration and hopelessness I forgot a couple of things:  That we have a very enthusiastic community of engineers in Sun, willing to jump when someone else hits a snag, AND that these engineers are everywhere in the world. So not 30 minutes had passed, when there was an email from Kyeungchul Kim , from Korea (mid night for me, mid morning for Kim) suggesting similar approach to what we had done already, but in the last line of his notes, there was light at the end of the tunnel:
   

   "This 
   problem is fixed in Weblogic Server 9.2 MP1."
   

After validating with the application engineer , I started downloading Weblogic Server 9.2 MP2. We are past midnight now and the download time was 25 minutes. My thoughts: Only 25 minutes?, a sweet wait of half and hour to find out if it was as simple as that , and it was.

End of the story: App Servers installed, application was deployed by the app engineer and success criteria was met for the field account team and the customer. Is kind of cool when things go right.

Thanks to Kim for his right on target tip.

Unas 3 semanas atras, tuvimos una carga de trabajo fuera de lo normal en el SSC Fort Lauderdale. Teniamos muchos equipos que configurar y sobre los que trabajar desde el ambiente de clientes delgados Sunray. En una de esas largas noches, mi "desktop" de la oficina tenia como 10-12 terminales abiertos con consolas conectadas a distintos servidores y arreglos de discos, amen de otras ventanas con browsers tambien conectados a sistemas  de administracion varios.

Nuestro modelo de clientes delgados Sunray , es realmente ideal para este tipo de ambientes, porque necesito moverme entre dos laboratorios y mi puesto de trabajo. En cada uno de estos sitios hay sunrays disponibles, por lo que puedo llevarme mi Desktop a cualquiera de estos 3 sitios.

El tema aqui era el llevarme ese mismo ambiente a mi casa, para continuar con la preparacion de los servidores , donde obviamente no estaria conectado a la LAN de la oficina. Ahi fue donde recorde que uno de nuestros modelos, el Sunray 2, permite la conexion remota via Internet. Me lleve uno de estos appliances o "libritos" para mi casa y lo conecte a mi switch de internet.(El teclado, Monitor y mouse se lo quite prestado a mi esposa :-) .

La configuracion del cliente delgado es bastante sencilla, incluyendo los parametros de la VPN que tenemos que preparar para entrar a nuestra intranet. No me tomo mas de 5 minutos seguir las instrucciones. Fue una sorpresa muy agradable el insertar mi tarjeta/carnet de la oficina en el sunray 2 y ver mis 15 terminales , browsers , etc en la comodidad de mi casa. El tema del desktop virtual es sencillamente una realidad muy comoda.

Que tan rapido es el desktop?. Yo tengo una conexion de 1Mb, veo todo perfecto, me atreveria a decir que mejor que en la oficina.

Tomando en cuenta el precio de la gasolina en estos dias ($60 llenar un tanque ) la alternativa de quedarse en casa tiene mucho atractivo, sobre todo si me puedo llevar el ambiente de trabajo con tanta tarnquilidad, y seguridad

I had the chance to run an install exercise of Sun Cluster 3.2 with Solaris Volume Manager and QFS as the file system last week. The infrastructure used was

• Sun Fire 6800 , 2 domains
• Brocade 4900, 2 zones
• STK 3510
• Solaris 10 U4
• Sun Cluster 3.2
• Sun QFS 4.6
  

The details of the process are   here

 

 

I had a chance to run some I/O characterization for a DB2 database in the SSC FT. Lauderdale in the last month and the results are worth writing about. The task was simple, to contrast the behavior of the IMPORT vs. the LOAD command for a large amount of data (20 Million records in our test table)

The documentation on these 2 commands points to a clear difference both in the method used to load the data and in the throughput and efficiency of the load. They are:

• IMPORT uses SQL to insert data from an structured form into a table, it fires triggers if they are present.

• LOAD uses low-level access techniques to populate the tables. Triggers are not fired and constraint checking can be deferred
  

There are several other differences documented in the DB2 site, but in general the recommendation for loading massive amounts of data is to use LOAD instead of IMPORT. Let's see how we got data to backup these statements.

Am using DB2 9.1.3 for Solaris, which comes with an automatic storage option which basically takes care of optimizing. The database was created with the command:

# db2 "CREATE DATABASE TEST AUTOMATIC STORAGE YES ON '/DB' , '/DB1' PAGESIZE 32768"

For the interest of the test we also want to separate the logs from the containers so we issued the command

# db2 “update db cfg for TEST using NEWLOGPATH /LOGS”

and then :

# db2start
# db2stop

Restarting the DB2 Instance so we are sure that the logs will be created in the new path. I noticed that the creation of the log files ( S0000xxx.LOG ) takes place the first time the connect command is issued. There is big spike in the I/O system. The number of logfiles and their size depend on the variables set for the database. I had set them up to

# db2 update db cfg for banco using logfilsiz 65535
# db2 update db cfg for banco using logprimary 50


Which means that each log would be of 256 Mbs (65535 * 4 Kbs), and that there will be 50 files created (S0000001.LOG...S0000050.LOG)

I had 3 filesystems setup for this test. /DB, /DB1 and /LOGS in a STK 6140.The /etc/vfstab looked like this:

.../rdsk/c5t600A0B80002624EA00000CB5476C2A0Bd0s6 /DB ufs 2 yes noatime,forcedirectio
.../rdsk/c5t600A0B8000261D7000000CE4476A2F0Cd0s6 /DB1 ufs 2 yes noatime,forcedirectio
.../rdsk/c5t600A0B8000261D7000000D03476C2A9Ed0s6 /LOGS ufs 2 yes noatime,forcedirectio


When a load command is issued, the behavior of the IO reflects the statement indicated above since the data is loaded directly to the filesystems designed for the containers (/DB, /DB1). No activity is performed in the /LOGS file system. This is very interesting since the “low level commands” indicated in the literature seem to bypass the use of the LOGs file system and go directly to the database, spreading the writes  evenly among the containers. The graph below shows the writes in KB/s for the 3 busiest disks on the server. In the graph, the red is the /DB1 and blue is the /DB. Between the 2 file systems the throughput is 60 Mb/s and the total load time is 4 minutes.

 
The behavior contrasts heavily with that of the IMPORT utility, since the use of SQL commands to insert the data in the database, works updating the LOGs file system first and then the the database, with periodical peaks of write operations to these containers, something that is most likely attributed to the “commitcount” parameter of the IMPORT command executed. In the graph, green is /LOGs , Red is /DB1 and Blue is /DB. The aggregated throughput of the containers is around 2 MB/s with peaks of 7 MB/s and a total load time of 71 minutes.

CPU consumption remain similar in both cases, with very little demand of computing resources. Based on these results (LOAD 4 minutes, 60MB/s vs IMPORT 71 minutes, 2MB/s) we can backup the statement of using LOAD instead of IMPORT for large amounts of data. This is off course an over simplified scenario that can only be used as a baseline for a comparison between the 2 utilities.

 

Ayer en la tarde, me dieron la llave del acceso al DNS para cambiar el nombre del acceso al Site del SSC. El nombre anterior de la direccion que estamos usando fue diseñado para no llamar la atención, por lo que es hasta difícil de recordar (b2t8q2i8). Pues teniendo la llave, y con el impulso de las compras nerviosas, decidí cambiarle el nombre al hostname para que de ahora en adelante quien quiera conectarse al laboratorio solo tenga que ir a:

https://ssc.la-solutioncenter.com

Mas fácil y, espero, mas nemotécnico para recordar.

Todo bien hasta aqui, el problema es que hasta donde entiendo (y reconozco que es por falta de investigación adicional), La instalación de SGD debe tener el hostname claramente referenciado por los dns que lo resuelven. Lo que quiere decir que mi cambio impulsivo a ssc, genero que no tuviera servicio de acceso remoto en la mañana de hoy. Teníamos dos alternativas:

1. Cambiar el nombre del servidor en el DNS a su nombre original , o
2. Cambiar la instalación para que reflejara el nuevo nombre (ssc.la-solutioncenter.com).

La primera solución era la más sencilla, pero también la menos entretenida y sin aprendizaje. Optamos por la segunda y dejamos la primera como rollback en caso de que no nos salieran las cosas bien. Tenemos un servidor que estamos preparando para la migración a la versión 4.4, sobre el que ya escribí lo sencillo que es la instalación inicial en el post anterior. El plan era el siguiente:

1. Sacar respaldo al servidor actual (respaldo del SGD, no del OS)

2. Desconectar la interfaz que se comunica con internet (via firewall) para evitar conflicto de IP posteriormente

3. Desinstalar la versión 4.4 del nuevo servidor

4. Configurarlo como el nuevo servidor ssc asumiendo la misma dirección IP del servidor anterior

5. Instalar SGD version 4.31 en el nuevo servidor y configurarlo para trabajar via ssl

6. Recuperar los datos necesarios respaldados en el punto 1

Veamos como nos fue.

1. Sacar respaldo al servidor actual . De acuerdo a http://docs.sun.com/source/819-6255/installation_backup_recovery.html el respaldo de una instalacion SGD es basicamente respaldar el directorio de instalación que generalmente es /opt/tarantella.El link pide previamente el comando de hacer achives de los logs, asi que hicimos:
   /opt/trantella/bin/tarantella archive
   tar cvf tarantella.tar /opt/tarantella/* . Son com 440 Mbs de espacio

2. Desconectar la interfaz del servidor SGD actual. El servidor tiene dos interfaces, una para la red interna y otra, la que se conecta a internet. Esta última fue desconectada. La primera nos sirve de acceso para pasarle el archivo tar al nuevo servidor.

3. Desinstalar la versión 4.4 se hace tambien de manera sencilla a través de SGD
   /opt/tarantella/bin/tarantella uninstall

4. Configurar el nuevo servidor ssc.Esto lo hicimos con un sys-unconfig para dejar limpias la interfaces y empezar nuevamente. Dos interfaces, una para la red interna y otra para

5. Instalar SGD version 4.31. El software viene en formato pkg y se puede bajar de sun.com. Su instalacion requiere

   1. Creaciòn de los usuarios ttasys y ttaserv.

   2. Ejecutar el pkgadd -d tta-4.31-905.sol-x86.pkg (nuestro servidor es x86)

   3. Luego de la instalacion ejecutar el /opt/tarantella/bin/tarantella start. Este comando al ejectuarse por primera vez configura al servidor. Adicionalmente necesitamos que la conexion sea segura, por lo que activamos ssl.Hay un par de posts muy buenos para hacer esto en el blog de Fat Bloke http://blogs.sun.com/fatbloke/entry/there_can_be_only_one y http://blogs.sun.com/fatbloke/entry/securing_the_connections_between_the . Ambas nos permitieron hacer que el trafico solo vaya por el puerto 443 encriptado. Al terminar cone stos pasos, ya podiamos ver el servidor desde internet. Sin embargo no teniamos ni los usuarios ni los entornos que habiamos configurado para ellos. Eso se hizo en el paso 6

6. La recuperación de los datos para que el nuevo servidor asumiera la identidad del anterior fue asi

   1. ftp del archivo tarantella.tar desde la máquina original a este nuevo servidor.

   2. Despues de revisar la información que se respalda, nos pareció que lo mas importante a recuperar era el directorio del repositorio local ENS.
      tar xvf tarantella.tar -C /opt/tarantella//var/ens. Este directorio tiene toda la informacion de las aplicaciones disponibles, la organización, etc. Luego de correr el tar, bajamos y subimos el SGD (/opt/tarantella/bin/taranella restart) y listo todo.
      Bueno no todo. Nuestro mecanismo de autenticación actual es unix (esta pendiente migrarnos a LDAP) por lo que los usuario estaban creados en el otro servidor, no en el actual. Maria Avlila,  hizo la cirugia de passwords y home directories y ahora si, estamos live from Ft. Lauderdale bajo el link http://ssc.la-solutioncenter.com

La ventaja es ahora , que tenemos la instalacion anterior para hacerle el upgrade a la versión 4.4 y probar antes de hacer la migración del servidor de producción. Sigue estando pendiente además la autenticación via LDAP. Ya vendrá y pronto.

Sites de Referencia utilizados:

http://docs.sun.com/app/docs/doc/820-2549
http://www.sun.com/download/products.xml?id=4717e2a2
http://docs.sun.com/source/820-2550/index.html

---
Lo primero es crear las cuentas ttasys y ttaserv. Este paso es indispensable porque el instalador no crea los usuarios y si no los encuentra, la instalación falla. Siguiendo la guia de instalación.:
---

root@x2100-2 # groupadd ttaserv
root@x2100-2 # useradd -g ttaserv -s /bin/sh -d /export/home/ttasys ttasys
root@x2100-2 # useradd -g ttaserv -s /bin/sh -d /export/home/ttaserv ttaserv
root@x2100-2 # passwd -l ttasys
passwd: password information changed for ttasys
root@x2100-2 # passwd -l ttaserv
passwd: password information changed for ttaserv
root@x2100-2 #

---
Aquí hay un detalle particular y es que el comando no crea los directorios home de los usuarios, por lo que habria que crearlos manualmente antes de ejecutar la instalación del SGD.
Luego instalar es simplemente agregar el paquete tta 4.40:
---
pkgadd -d tta-4.40-907.sol-x86.pkg

The following packages are available:
  1  tta     Sun Secure Global Desktop Software for Intel Solaris 10+
             (x86) 4.40.907

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:

Processing package instance <tta> from </tta-4.40-907.sol-x86.pkg>

Sun Secure Global Desktop Software for Intel Solaris 10+(x86) 4.40.907

Sun Microsystems, Inc.


--------------------------------------------------------------------------
Setting up Sun Secure Global Desktop Software
--------------------------------------------------------------------------
Secure Global Desktop Setup recommends you use the following settings:

Installation type = reinstall 4.40.907
Installation directory = /opt/tarantella

Are these settings OK?
  Y - Yes, install using these settings
  N - No, tell me more about the options and let me change the settings
  Q - Quit now

OK to use these settings? [Y]

---
omitiendo el detalle de los archivos instalados
---

## Executing postinstall script.

To complete the installation, please run /opt/tarantella/bin/tarantella start


Installation of <tta> was successful.


---
Listo, ahora, como sugiere la penúltima línea, arrancamos al global desktop
---

root@x2100-2 #  /opt/tarantella/bin/tarantella start

--------------------------------------------------------------------------
Secure Global Desktop Software License Agreement
--------------------------------------------------------------------------
To use Secure Global Desktop you must agree to be bound by
the terms of the Software License Agreement.

  Y - I have read, and accept the terms of the license agreement
  N - I do not accept the terms of the license agreement
  R - Let me read the license agreement

Accept terms of Software License Agreement? [R] Y


--------------------------------------------------------------------------
Setting up Sun Secure Global Desktop Software
--------------------------------------------------------------------------
Secure Global Desktop Setup recommends you use the following settings:

Installation type = install 4.40.907
Peer DNS name = x2100-2.LA-SolutionCenter.com
HTTP port = 80 [not currently in use]
Archive logs every week? = yes (Sunday 03:00 hours)

Are these settings OK?
  Y - Yes, install using these settings
  N - No, tell me more about the options and let me change the settings
  Q - Quit now

OK to use these settings? [Y]
--------------------------------------------------------------------------
Configuring your installation...
Running templates Setup script...OK
Running files_rename Setup script...OK
Running dbcreate Setup script...
tarantella.config.tuning.heapsize.initial = 40
tarantella.config.tuning.heapsize.max = 80
tarantella.config.tuning.heapsize.absmax = 2048
Configuring and starting Secure Global Desktop web server...
Running wcp/configchanges Setup script...OK
Running tsp/resources Setup script...OK
Running 3270/resources Setup script...OK
Running 3270/configchanges Setup script...OK
Running 3270/purge Setup script...OK
Running 5250/resources Setup script...OK
Running 5250/configchanges Setup script...OK
--------------------------------------------------------------------------
What's next?
--------------------------------------------------------------------------
Secure Global Desktop is now installed and ready to use.

To get started:

 - In a web browser, go to:
   http://x2100-2.LA-SolutionCenter.com/
 - When prompted, log in with username "Administrator" and root's password.
 - On your webtop, click Administration Guide to learn more about the product
   (we strongly recommend you read the "Getting started" section).

To add license keys, type:
/opt/tarantella/bin/tarantella license add <key>...
--------------------------------------------------------------------------
Successfully installed Sun Secure Global Desktop Software
--------------------------------------------------------------------------
root@x2100-2 #

Esta es la instalación básica del SGD. en un próximo post haremos:

• Activación de SSL para conexión segura
• Migración de la versión 4.31 a la 4.4
• Incorporación de un Ldap Server para autenticación.El Ldap irá en una zona
• Tener 2 servidores para hacer failover
  

Esta semana ha estado interesante laboralmente. Primera visita a Hillsboro, Oregon a este Sun Solution Center http://www.sun.com/solutioncenters/locations/hillsboro/ para una prueba de concepto sobre una M9000 con base de datos DB2.También es la primera vez que toco una M9000 directamente, 28 dual-core cpus, 56 cores, 112 threads...medio TB de memoria, una pelusita dirían en Chamariapa.

La máquina la configuró Mark Dennis, Ingeniero de infraestructura del SSC Hillboro, con una sola partición en modo UNI-XSB.

Lo cierto es que la instalación ha estado bastante movida porque DB2 no queria instalar en la M9000. La versión que instalamos inicialmente era la 9.1.0.0 , proveniente de una instalación anterior en una v490 con Solaris 10 update 3. En esta oportunidad la instalación falló con el siguiente (y fatídico ) mensaje al momento de ejecutar el comando db2start:

11/06/2007 19:19:43 0 0 SQL1042C An unexpected system error occurred.

SQL1032N No start database manager command was issued. SQLSTATE=57019

Como le hicimos troubleshooting?. Existen varios postings via google que apuntan a:

• Revisión de la permisología de algunos archivos

• Cambio de passwords del usuario db2inst1

• Revisión de los puertos en los que corre el servicio de base de datos (/etc/services)

Muchos de los problemas descritos tenían que ver con lo que pasaba después de instalar. En nuestro caso sin embargo el error se presentaba al momento de instalar. DB2START simplemente se estrellaba.

Buscamos y buscamos hasta que alguien nos sugirió que instaramos Fixpak 3a. Eliminamos la instalación 9.1.0.0 y montamos el 9.1.0.3 FIXPAK 3a. Eso resolviò el problema. Tenemos entonces una M9000 con DB2 y 112 threads listas para trabajar.

Los aderezos de este plato principal son:

• Solaris 10 Update 4

• 1 HBA Emulex dual port 4Gb. Ambos puertos activos y conectados a la SAN. Multipathing is enable (stmsboot -e)

• 1 switch Brocade

• 1 6140 dos Controladoras , 4Gbs

Nombre del hostname.... LABRADOR....como San Isidro.

Recién instalamos el software Secure Global Desktop para manejar acceso remoto al Solution Center. Ahora tenemos una dirección pública a la que los usuarios (clientes, empleados, partners) pueden conectarse y usar para acceder a los recursos del centro. La verdad es que la herramienta es una gran ayuda en varios aspectos:

Se puede desplegar practicamente cualquier aplicación de manera remota, incluyendo:

• El terminal X (xterm, gnome terminal, dtterm... etc)

• Sesiones completas de gnome, en pantalla completa o dentro de un browser

• Windows, Linux, Solaris, y otros más.

Acceso remoto via web seguro. Hacer “click” en un link es muy cómodo para los usuarios, le damos un usuario/password a los empleados y clientes que lo necesiten y asi les permitimos entrar de manera rápida a nuestro centro.

Control del contenido. A diferencia de una VPN , aqui podemos definir las aplicaciones a las que queremos dar acceso. Demostraciones como la que recién instalamos de Virtual Tape Library (VTL) podemos asignarlas de manera individual o por grupos

Shadow.. casi tan bueno como la shadow spirit de la honda.. Este feature es uno de los que más me llama la atención. Un administrador del SGD puede pedirle a cualquier usuario que se encuentre en una sesión, que le permita “colaborar” con él manera simultánea. Si acepta, la sesión del usuario remoto se muestra de manera  ambas personas. Ambos pueden ver y trabajar al mismo tiempo. Esto es muy valioso si queremos hacer una demostración en vivo de una tecnología en particular, como en el caso de como configurar un M5000, o un 6140, o unos LDOMS.. Se puede hacer todo en “vivo y directo via SGD”.

Un ejemplo práctico del valor que me da esta herramienta en el centro, es el de esta semana. Tenemos una prueba de concepto (POC) para la que viajaron 4 personas desde Colombia hasta acá en la Florida. Sin embargo, por razones particulares el uno de las administradoras de sistemas no pudo viajar. Le dimos acceso a la máquina y se pudo conectar, configurar usuarios, descargar el backup que nos envió en cinta y  trabajar conjuntamente con las personas que se encuentran aqui.

Al final del viaje, si queda algo por hacer.... lo pueden hacer de manera remota. Todo unn cuento de hadas..

El SSC FT. Lauderdale abierto aqui..https://b2q8t2i8.la-solutioncenter.com/

Desde la incomodidad del espacio y los tiempos de un avión , leí en una revista la sugerencia de uso de Vmware como alternativa para virtualizazción del ambiente de escritorio. Me pareció hasta curioso porque la orientación de la revista es para usuarios de PC, no para usuarios empresariales. Además, el avión me traía a escuchar la conferencia técnica más importante del año en SUN, el Customer Engineering Conference (CEC), en donde seguramente escucharía hablar de Vmware como uno de los tantos enfoques que buscan sacarle más y mejor cómputo al hardware. La idea y el artículo se quedaron dando vueltas en la memoria.

Lo cierto es que me pareció interesante hacer la prueba por mi mismo tomando en cuenta que tengo una laptop que pareciera haber sido diseñada para virtualización:

• 2 Núcleos en el procesador AMD Turion 64 X2 2.20 Ghz

• 2 GBs de Memoria RAM

• 2 Discos duros internos 120GB, 7200 Rpms

El sistema operativo de esta laptop es Windows Vista Home Premium. Ya había tratado anteriormente de instalarle Ubuntu o Solaris sin éxito, debido principalmente al tema del los drivers de Video (Nvidia Geoforce Go 150) y Wi-Fi (Broadcom). Los sabores de Vmware que quería probar sin embargo corren directamente sobre Windows Vista (el host OS) por lo que la comunicación con el hardware ya está manejada por Windows, Vmware se recuesta de esto y virtualiza lo que ya Windows maneja.

El primer software que probé fue el Player. Como su nombre lo dice, el player me permite correr cualquier máquina virtual existente, y que están convenientemente ubicadas (o linkeadas) en el site www.vmware.com . Encontré una instalación de Debian y una de OpenSolaris(B35). Bajé la de Debian para probarla y la verdad es que tanto la instalación del player como la de la máquina virtual fueron muy sencillas. Al final de la jornada de recepción de bytes e instaladores todo funcionó como debía funcionar. Ahi estaba pues, una instalación virtualizada de Debian en mi laptop.

Sin embargo, la instalación me refrescó que el player requiere que alguien previamente haya trabajado en la creación de la máquina virtual. Ese alguien en este caso es el Vmware Server. Luego otro download e instalación estábamos listos para trabajar, solo necesitaba un sistema operativo en cd o dvd para crear la máquina virtual. Surgió la ocasión ideal porque me entregaron un dbd de Solaris Nevada build 74 en una “feria de instalación”.

La experiencia de instalación de la máquina es igualmente sencilla y agradable, con resultados que valen la pena anotar y compartir:

1. El tiempo que se toma la máquina virtual en arrancar es de unos 3 minutos, durante los cuales no se puede hacer nada mas que esperar. Pareciera que el principal recurso que se consume es acceso a disco. Esto sin embargo afecta a todo el ambiente.

2. El Vmware server permite crear máquinas virtuales de Solaris 9, 10 y Solaris 10 64bits. Opté por la opción de Solaris 10 32 bits porque Vista corre en 32 bits, aun cuando no he investigado que pasaría si lo instalara en 64 bits.

3. La instalación de Nevada B74 se quejó inicialmente cuando cree un disco virtual de 8GB, por lo que borré el primero y generé otro de 12GBs. Para tratar de evitar peleas en el disco, la nueva imagen la cree en el disco alterno a Vista.

4. La máquina virtual puede configurarse con 1 o 2 cpus (cores realmente). Le asigné un cpu y 888 Gbs de memoria y funcionó bastante decente en cuanto al rendimiento de aplicaciones como staroffice y firefox, aun cuando siempre se nota un poco que la máquina no ejecuta a la misma velocidad con la que lo hace el sistema operativo original (Vista en este caso). En un segundo intento le asigné 2 cpus, pero en este caso el resultado fue desfavorable con mucha lentitud tanto para Windows como para Nevada.

El otro aspecto interesante a resaltar es que este ejercicio me permitió crear una instalación de Solaris Nevada, a la que le luego le instalé el software Secure Global Desktop. Con esto pude practicar una instalación de software, documentarla y eventualmente transportarla a otro servidor si llegara a necesitar mas capacidad de cómputo y memoria.Es lo que planeo hacer al llegar a la oficina la semana entrante.

Claro que WMware es solo una de las alternativas de virtualización a probar en la laptop. Si estuviera partiendo de Solaris como sistema operativo en lugar de Windows Vista, los containers me hubieran dado un ambiente virtualizado mucho mas sencillo , migrable y con un rendimiento sin penalidades.

Por otro lado, estoy esperando un poco para probar la versión de xVMen Nevada para comparar experiencias en usabilidad y funcionalidad.

 

 

Desde hace una semana, estoy trabajando ahora en el Sun Solution Center (SSC) de FT. Lauderdale, una idea que no me es ajena porque alli fue donde empece con Sun Microsystems. En aquel entonces se llamaba iForce Ready Centers, con una intencion y responsabilidad similar a la que hoy en dia tiene el SSC. Que vamos a hacer aqui? :

• Pruebas de Concepto (POCs). Estas pruebas estan fundamentadas en una infraestrura, un datacenter con todas las prestancias de un ambiente de produccion (switches de red, fibra, servidores , almacenamiento, monitoreo,etc) con tecnologia de punta y con acceso a los tecnicos de Sun que disenaron los productos.
• Demos. Soluciones preconfiguradas que nos sirven para contar como se resuelve un problema . Involucran hardware, software , storage, etc.
• Workshops. Los que estamos aqui venimos de trabajar directamente con clientes asi que tenemos la vivencia de hacer arquitecturas que reflejan las soluciones a los requerimientos de los clientes. Los workshops nos ayudan a tener claridad sobre lo que el cliente desea y sobre lo que les podemos ofrecer.
  

Esto es para Latinomarica, asi que va a ser interesante y emocionante trabajar recreando situaciones y resolviendo problemas con nuestra maqueta de datacenter. 

Un par de semanas atrás apareció en las noticias internacionales, que el equipo de fútbol Manchester United firmó a un jovencito de 9 años para sus filas por sus habilidades con el balón. La noticia sin embargo no es esa, sino la manera en como hicieron el "scouting" del niño. El video de youtube  , que entiendo fue realizado por el abuelo del muchacho fue lo único necesario para que el Manchester decidiera incorporar al niño al equipo.

El hecho es curioso, pero además propicio para la reflexión. Que otros eventos podrían, o de hecho se apalancan en servicios audiovisuales como estos para crear situaciones, entrenamientos, eventos, etc.? Evaluaciones: Gimnasia, Artes Marciales, Canciones;  Entretenimiento: Novelas (lonlegirl15 es creo una de ellas con entregas periódicas), Cortos, Noticias; en fin opciones que permiten por un lado acortar distancias , reducir costos, ampliar el panorama de exposición de conceptos nuevos o existentes. Parece bueno esto...

Por otro lado y paradójicamente, este medio de transporte propicia la asincronía, reduce la necesidad de que los participantes se encuentren fisicamente para comunicarse e intercambiar. Parece no tan bueno esto. Habrá que encontrar un balance entre ambas consecuencias.

Powered by ScribeFire.

Desde hace un mes aproximadamente estoy incursionando en el  mundo del Karate-do Shotokan, con el Sensei Darwin Rojas y la Sempai Adriana Angulo en el dojo Showa-Kan. Una experiencia no solo interesante sino adictiva además por cuanto toca no solo la dimesión del consumo calórico y el ejercicio físico, sino además porque tiene historia, contenido, motivaciones, y difusión mundial con diferentes aristas de acuerdo a los distintos escenarios en los que se practique.

El arte marcial como tal fascina por la disciplina de la ejecución. Hay un protocolo que gobierna el comportamiento del practicante desde el momento que pisa el dojo, hasta el momento que sale de él. Existe una estructura jerárquica de rangos evolutivos de los practicantes que han decantado el arte, el contenido y las actitudes a través de la ejecución constante de los movimientos. Con lo poco que he podido absorber de este mundo, El Karate fascina, educa, ejercita la mente y el cuerpo, permite concentrar y liberar energías.

Aun cuando "los contenidos" que debemos aprender son probablemente estándares, creo que el método de enseñanza obedece mucho a la interpretación del sensei en como hacerlos llegar y permear a cada participante. El Sensei y la Sempai complementan muy bien un método en el que se aprende de manera "natural" usando los sentidos, tal como lo hacen  los niños; copiando lo que se ve, escuchando y asociando sonidos con movimientos, errando y entendiendo lo que está fuera del protocolo y no es permitido, en fin abriéndole espacio al arte marcial  para que entre y se decante. Esto se complementa a su vez con momentos conductistas, en los que la técnica y del movimiento es explicada para ofrecer un segundo ángulo de percepción. Es divertido ...

La vestimenta es algo bien particular. El uso del "traje" o Karategui con el cinturón resume y representa la formalidad y el rango de lo aprendido, pero a mi me parece además que el Karategui  entiende quien sabe llevarlo como Kartakeka y quien está aún entendiendo de que se trata el tema. Esto lo pude constatar personalmente luego de estrenar mi Karategui y encontrar mi imagen en el espejo del dojo frente a la de los compañeros, La Sempai y El  Sensei. Lo primero que me vino a la mente fue que todos ellos se veían como  karatekas, mientras que yo me veía mas bien como un chef. Espero tener la oportunidad de hacer que mi Karategui me acepte la transición de la cocina al dojo en el transcurso del tiempo.



Sensei Darwin Rojas, El Chef y la Sempai Adriana Angulo en el dojo ShowaKan

Esta semana arranca el JavaOne 2007 , un mega evento dirijido a desarrolladores a nivel mundial. Vale la pena estar atentos porque siempre aparece Jonathan haciendo anuncios importantes sobre el código, el esquema de licenciamiento (o mejor dicho el camino al código abierto de los distintos elementos de la plataforma Java), y otros. Hay algo particularmente interesante para mí en este evento. Ian Murdock  tiene una importante participación. Ian, como muchos saben es el fundador de Debian. Lo que tal vez no saben tantos, es que Ian trabaja desde hace poco con Sun Microsystems. Contar con su punto de vista, su conversación, sus ideas, y en general el sólo hecho de tenerlo como empleado de la compañía; dice mucho de la seriedad con la que Sun asume el reto de hacer que nuestro sistema operativo sea no solo el mejor del mundo en cuanto a robustez, escalabilidad, rendimiento, madurez; sino además el más atractivo para los desarrolladores. Lo digo porque una de las principales misiones de Ian es la de mejorar la "usabilidad" de Solaris para que los desarrolladores no tengan que ser además administradores de sistemas si quieren programar, crear aplicaciones, o simplemente utilizar Solaris (u OpenSolaris) como primera alternativa en sus estaciones de trabajo, pcs, laptops o cualquiera que sea su minicomponente de cómputo.

Puedo por demás constatar con experiencia propia que la evolución hacia una mejor usabilidad ya está en proceso. He instalado (y usado) en los últimos 6 meses 3 sabores derivados de Solaris:

• Solaris 10 11/06 
• Solaris Express Developer Edition (primer release, i.e. Build 55 de Nevada)
• Build 60 de Nevada
  

Los cambios y mejoras son notables desde el punto de vista de la facilidad de uso y la "experiencia del usuario". El build 60 viene remozado con una versión de Xorg mas reciente. Es Importante esto?, bueno, si fuera un desarrollador y me compré una laptop para programar en java php por ejemplo, contra un base de datos mysql o postgres a lo mejor si me importaría...

Por Qué ? (si ninguna de estas herramientas tiene directamente que ver con el "display" de una laptop). Ah, porque a lo mejor me gustaría tener abierto al mismo tiempo el IDE netbeans mientras estoy programando, el mysqladmin tools, y firefox con el resultado de lo que voy haciendo. Eso se puede hacer mucho mejor si la resolución del la pantalla se ve a todo su esplendor (aqui es donde Xorg entra).

Me ha gustado tanto lo que ví en este build 60, que en la búsqueda del sistema operativo para mi laptop (pasé de Windows por "default" a Ubuntu 6.06, a Solaris 10, a Ubuntu 6.10, a Nevada B55 , y finalmente a Nevada B60) creo que encontré la ruta. Y es que yo trabajo en una laptop todo el día, entre correos, propuestas, presentaciones, reuniones con clientes, etc. Es decir necesito un ambiente que me permita ser productivo, interactivo, demostrativo, educativo y  eventualmente divertido. Hasta ahora, los "detalles" de usabilidad que veía en Solaris 10 (como por ejemplo la dificultad para redireccionar el video a un projector) me incomodaban y me obligaban a tener la laptop "particionada" entre Windows (para proyectar y por si acaso) y el Solaris/Ubuntu/Nevada del momento. Sin embargo tengo alrededor de un mes con este build 60 de Nevada instalado y ya decidí eliminar Windows de la otra partición, ya no me hace falta. Las razones son sencillas.

En productividad

• Firefox, Thunderbird, Evolution, Staroffice 8 , todo incluido ( sin aditivios químicos y sin colesterol, como decían en aquella propaganda..)
• ZFS que es la octava maravilla, es impresionantemente facil de aprender, y es extremadamente poderoso
• SAMP...bueno, este paquete me lo tuve que bajar porque aun no lo veo integrado, pero una vez instalado está prefabricado para correr mysql, php, apache.. sin tener que tocar archivos de configuración. Además esta optimizado para Solaris.

En usabilidad:

• El video funciona (1200x800), puedo conectarme a una pantalla/proyector externo
  
• La red necesitó de algo de trabajo inicial porque mi driver (yukon) estaba desactualizado. Wifi no está aún pero ya me dijeron que sale en el build 64 .
• La interfaz de usuario es gnome en su mejor expresión.
• Los servicios (SMF) los puedo escoger, apagar, prender todos desde una consola, así no más
• El mejor piropo a este build  se lo dió Marietta, una compañera de trabajo, este pasado viernes en la oficina. Ella pasó por mi puesto a conversar sobre un tema en particular y al ver la laptop comentó lo "bonita" que se veía la pantalla. Marietta es usuaria de Windows en exclusividad, por lo que ver recibir el adjetivo "bonita" para el escritorio de Nevada me anima y complace además. Mucho hemos avanzado desde la época del frío e incólume CDE
  

Algo de esto se conversará esta semana en el JavaOne. No tengo el chance de asistir por compromisos locales, pero estaré pendiente de los blogs y de sun.com para escuchar los cuentos, seguramente serán agradables y esclarecedores.