Sun Virtual Desktop Infrastructure Software

First download the software from here

http://www.sun.com/software/vdi/get.jsp

Install Sun Ray Server Software:
Run the install command.
# ./utinstall
The installation process begins. The script first displays the text of the Sun Software License Agreement and prompts you to accept its terms and conditions. After reviewing the license agreement, answer y (yes) to the prompt.

The utinstall script checks to see which SRSS components are already installed and displays the results. It prompts you for a response before it installs the required software products and any necessary patches. Answer y (yes) to the prompt.

Finally, it prompts you for the location of the Java Runtime Environment, version 1.5 or later.
Tip :Be sure to use a 32-bit JRE regardless of whether you use a 32-bit or a 64-bit operating system.

It prompts you for a response before it installs the required software products and any necessary patches (Solaris only). Answer y (yes) to the prompt.

The utinstall script ends. A time-stamped log file is available at:
/var/adm/log/utinstall.year_month_date_hour:minute:second.log

Configure the Sun Ray Server on a LAN

# cd /opt/SUNWut/sbin
Configure the Sun Ray LAN subnet:
# ./utadm -A subnet#
Where subnet# is the name (really a number) of the subnet, such as 192.168.128.0.

The utadm script begins configuring DHCP for the Sun Ray interconnect, restarts the DHCP daemon, and configures the interface. The script then lists the default values and asks if they are acceptable.

If you are satisfied with the default values, and the server is not part of a failover group, answer y.

Otherwise, answer n and accept whatever default values are shown by pressing return or provide the correct values from the worksheet.
The utadm script prompts for the following:
      New netmask (255.255.255.0)
      New first Sun Ray DTU address (192.168.128.16)
      Total number of Sun Ray DTU addresses
      New authorization server address (192.168.128.1)
      New firmware server address (192.168.128.10)
      New router address (192.168.128.1)
      To specify an additional server list. If you answer yes, it requests either:
          File name (filename)
         Server IP Address (192.168.128.2)

The utadm script again lists the configuration values and asks if they are acceptable. Answer appropriately. If you answer n, go back .
If you answer y, the utadm script configures the Sun Ray DTU firmware versions and restarts the DHCP daemon.

Turn the Sun Ray LAN connection on:  # /opt/SUNWut/sbin/utadm -L on

Restart services as prompted:  # utrestart

Configure Sun Ray Server Software
Open a shell window and change to the following directory:
# cd /opt/SUNWut/sbin
Configure Sun Ray Server Software.
 # ./utconfig

The utconfig script prompts for the following:
Whether the script should continue (press Return)
      Sun Ray administration password (adminpass)
      Sun Ray administration password again
      Path to the Apache Tomcat installation directory (/opt/apache-tomcat)
      Web server port number (1660)
      Whether to enable secure connections ([y]/n)
      If Yes, to enter HTTPS port number (1661)
      To supply a user name for the Tomcat process (utwww)
      Whether you want to enable remote administration ([y]/n)
      Whether you want to configure Kiosk Mode ([y]/n). If yes, it requests:
         User prefix (utku)
         Group (utkiosk)
         User ID range start (150000)
         Number of users (25)
      Whether you want to configure for a failover group
      Whether the script should continue (press Return)

The utconfig script begins configuring Sun Ray Server Software.
The Sun Ray Data Store is restarted.
The utconfig script ends, indicating a log file is available at the following locations:
     /var/adm/log/utconfig.year_month_date_hour:minute:second.log
Where the year, month, etc are represented by numeric values reflecting the time utconfig was started.

Installation Procedure Sun Ray Windows Connector:

Before running the installer, create a dedicated group for the sole use of the Sun Ray Connector.
 # groupadd <group-name>
where group-name is the name you assign to this group. The first character of the name must be alphabetic. Do not add users to this group.

Install the Sun Ray Connector software.
# ./installer
The installer prompts for the name of the group you want to use for the Sun Ray Connector.
Enter the name of a pre-existing group for use by Sun Ray Connector:
Enter the name of the group you created for this purpose at the beginning of this procedure, as below, then Continue:
     group-name
Run the automatic configuration script.
     # /opt/SUNWuttsc/sbin/uttscadm -c
The uttscadm script launches the SRWC proxy daemon uttscpd and adds an    entry for uttscpd in the /etc/services file, using port 7014 as the default

Restart Sun Ray services if the script asks you to do so.
     # /opt/SUNWut/sbin/utrestart

Installing Sun™ Virtual Desktop Connector 1.0

Each of the Sun Virtual Desktop Connector’s three layers — virtualization, desktop access, and session management — has associated installation tasks that must be performed.

Virtualization Layer

VMware Infrastructure 3 Product Evaluation

You can download the evaluation copy of the software from here

https://www.vmware.com/tryvmware/p/download.php?eval=vi3

Installing VMware VirtualCenter

To install VMware VirtualCenter, follow the instructions on the VMware Website at
http://www.vmware.com/support/pubs/vi_pubs.html.

1. Locate the Installation and Upgrade Guide.
2. Select “Installing VMware VirtualCenter”.
3. Make sure that:
a. Ports 6060 and 6061 are enabled in any firewall that may be active on the system.You can disable the firewall initially to check the installation.
   The Virtual Desktop Connector agent, which needs to be installed on VirtualCenter, uses these ports to communicate with the outside world.
b. VirtualCenter’s Webaccess component is installed and configured.
c. A user account with sufficient privileges is defined

Installing the Virtual Desktop Connector Agent

To install the Virtual Desktop Connector agent for use with VirtualCenter:
1. Locate the vda-agent.msi installer file in the directory where you have unzipped the vda_1.0.zip archive.The vda-agent.msi is located in the ./image/vda_1.0/Windows/Packages/ subdirectory.

The default location for the VirtualCenter agent on Windows is <a-z>:\Program Files\Sun\Virtual Desktop Access\Agent.

2. Double-click the installer and follow the prompts to complete installation.Your Services list should now contain a new service named Sun Virtual Desktop Connector Agent, running and set to start automatically.

Defining Virtual Machines and Templates
Creating a Virtual Machine Template
To configure a virtual machine for use as a template:
1. Create a Microsoft Windows XP virtual machine using the instructions in “Creating Virtual Machines” in Basic System Administration
(http://www.vmware.com/support/pubs/vi_pubs.html).
2. Install Windows XP, following the instructions on the Microsoft Website (http://www.microsoft.com/windowsxp/using/setup/winxp/install.mspx).
3. Make sure that networking is configured and that the virtual machine can get an IP address.At this point, you should also install any additional software for your virtual machines.

Installing VMware Tools
Once you have created a virtual machine with Microsoft Windows XP installed on it, install VMware tools. See “Installing and Upgrading VMware Tools” in Basic System Administration (http://www.vmware.com/support/pubs/vi_pubs.html).

Installing Virtual Desktop Connector Tools

For the Virtual Desktop Connector to manage virtual machines properly, the Virtual Desktop Connector Tools, which handle RDP connections when a guest OS initiates a standby, must be installed on the guest operating system.

Note – Be sure to enable time synchronization between the guest OS and the virtualization host. The Virtual Desktop Connector tools and the recycling process rely on it and cannot function correctly without it. For detailed setup information,see the instructions on the VMware Website at
http://www.vmware.com/support/gsx3/doc/tools_guestd_sync_gsx.html.

To install the Virtual Desktop Connector tools:

1. Locate the vda-tools.msi installer file in the directory where you have unzipped the vda_1.0.zip archive.The vda-tools.msi is located in the ./image/vda_1.0/Windows/Packages/ subdirectory.
2. Double-click the installer and follow the prompts to complete installation. The default target location for the Virtual Desktop Connector tools on  Windows is <a-z>:\Program Files\Sun\Virtual Desktop Access\Tools.
Your Services list should now contain a new service named Sun Virtual Desktop Connector Tools, running and set to start automatically.

Enabling Remote Desktop Access
To enable remote desktop access, launch VMware’s Virtual Infrastructure Client,with your virtual machine still powered on and logged in, then follow these steps:
1. Open a console.
2. In the console, click on the virtual machine’s Start button.
3. Right-click on My Computer on the start menu, and select Properties.

4. In the System Properties window, select the Remote tab.
5. Under Remote Desktop, check the box marked Enable Remote Desktop on thiscomputer so that this item is selected.
6. Click OK to save the settings and close the dialog.
You can now shut down the virtual machine by selecting Shut Down from the Start menu.

System Preparation (sysprep) and Customization
Before VirtualCenter can use customization specifications to customize virtual
machines, you must install the Microsoft System Preparation Tool (sysprep) on the
server running VirtualCenter. See Appendix B in Basic System Administration
(http://www.vmware.com/support/pubs/vi_pubs.html).
1. Install sysprep on the VirtualCenter Server.
a. Download the sysprep package from:
http://www.microsoft.com/downloads/details.aspx?FamilyId=3E90DC91-
AC56-4665-949B-BEDA3080E0F6&displaylang=en
b. Unpack to a directory, for example:
C:\Documents and Settings\All Users\VMWare\VMWare VirtualCenter\sysprep\xp
2. Create a Customization Specification. A customization specification stores settings that VirtualCenter can use to customize a Windows installation during the cloning process. To create a customization specification:
a. Open Virtual Infrastructure Client.
b. Click Edit from the menu above the tool bar and select Customization Specifications...
c. Click the New icon in the Customization Specification Manager to start the wizard.
d. On the first wizard step, choose Windows as the target virtual machine OS,and give the specification a name and description.
The following steps ask the standard Windows installation questions and should be completed to correspond with your requirements, with exception of the following:

- Computer Name
Make sure that the Use the Virtual Machine Name item is selected. If not,you may end up with duplicate hostnames.
- Windows License
Enter your Windows XP serial number. The Include Server License Information item should be unchecked.
- Networking
Make sure the interface is configured for DHCP. If not, your cloned virtual machines will not have unique IP addresses and will not work with the Sun Virtual Desktop Connector.
e. After completing the wizard and saving your customization specification, close the Customization Specification Manager.
3. Test the Customization Specification and Networking. At this point you should have a Virtual Infrastructure Client open and the template virtual  machine you created earlier shut down.
a. Right-click the virtual machine in the left pane, and select Clone.
b. In the Clone Virtual Machine Wizard, choose a name for the new virtual machine (such as Clone_Test), and click Next.
c. Choose the host or cluster that you want to run the new virtual machine, and click Next.

d. Select a data store with sufficient free space, and click Next.
e. On the Guest Customization step, select the Customize Using an Existing
Customization Specification radio button, then choose the customization
specification you just created from the list, and click Next.
f. Review your selections, and click Finish to begin cloning.
g. After the test virtual machine has finished cloning, select it in the left pane,
and power it on.After it has finished booting, you should see its IP address and hostname appear in the right pane. Make sure that it has a unique IP address and that the hostname corresponds to the virtual machine name.
h. On the VMware VirtualCenter server, open a Remote Desktop Connection
by clicking Start->All Programs->Accessories->Communications.

i. In the Remote Desktop Connection window, enter the IP address of the newly cloned test virtual machine, and click Connect.
If everything is configured correctly, a full-screen Remote Desktop session toyour test virtual machine should be displayed.If the Remote Desktop Connection client cannot connect to the virtual machine,you must resolve the issue before continuing. See “Networking” on page 36 for
possible issues.If you can get a Remote Desktop Connection to your test virtual machine and it has a unique hostname, the original template virtual machine you created is ready to be used.

Recent approaches to desktop architecture address the problems of a thick client architecture by using a centralized model in which applications are delivered as services to users on any device. This gives the IT organization the flexibility and control to deliver only those services that are necessary for the individual user. Thus, overall TCO is reduced and manageability improved. Built around the simplicity of thin client devices such as the SunRay™ultra-thin client, a centralized desktop architecture provides access to applications running on Microsoft Windows, the Solaris™Operating System(Solaris OS), and other platforms from a single desktop. Users can access the applications they need, and administration of the system is simplified. The desktop runs no software or operating system, so it never needs upgrading. Users can also choose the ease-of-use and low cost of alternative, open source productivity software such as the Star Office™Office Suite and Mozilla™. In the datacenter, a consolidated server solution runs the operating systems so that updates happen at one place and are immediately available to all desktop users. It is not sufficient from an implementation perspective to simply select hardware and software alternatives. Organizations need to evaluate, design, and plan the whole life-cycle of their desktop environment, and project teams need to address the three vital life-cycle components: their people, their processes, and their technology. Decision Areas : There are three major areas of choice confronting the designer of a desktop architecture: ■ Client-centric versus server-centric computing ■ Proprietary versus open source operating platforms ■ Client device type(s) The factors that need to be considered when making these choices are also the primary drivers that have to be understood and optimized by IS and IT management: ■ Total cost of ownership (TCO) ■ Manageability ■ Security ■ Usability and performance

Debugging Methodology :

The malloc() and free() memory management methods are used by many application developers. An application can be written without a dependence on any particular memory management programming interface by using the standard memory management methods malloc() and free(). This section will outline the steps needed to take advantage of the libumem library to debug an application's memory transactions.

Library Interposition and libumem Flags

If the libumem library is interposed (by setting the LD_PRELOAD environment variable) when executing an application, the malloc() and free() methods defined within the libumem library will be used whenever the application calls malloc() or free(). In order to take advantage of the debugging infrastructure of the libumem library, one needs to set the UMEM_DEBUG and the UMEM_LOGGING flags in the environment where the application is being executed.  The most common values for these flags are as follows: UMEM_DEBUG=default and UMEM_LOGGING=transaction.  With these settings, a thread ID, high-resolution time stamp, and stack trace are recorded for each memory  transaction initiated by the application.

The following are examples of the commands used to set the appropriate debug flags and interpose the libumem library when executing an application.


(csh)

%(setenv UMEM_DEBUG default; setenv UMEM_LOGGING transaction;
setenv LD_PRELOAD libumem.so.1;)

or

(bash)

bash-2.04$UMEM_DEBUG=default UMEM_LOGGING=transaction LD_PRELOAD=libumem.so.1

More details about the debug flags (UMEM_DEBUG and UMEM_LOGGING) can be found in the umem_debug(3MALLOC) man page.

MDB Commands

The developer can view the debug information pertaining to an application's memory management transactions by using MDB.  The following commands within MDB can be used to provide a great deal of information about the memory transactions that took place during the execution of the application.

::umem_status

    * Prints the status of the umem indicating if the logging features have been turned on or off

::findleaks

    * Prints a summary of the memory leaks found within the application
::umalog

    * Prints the memory transactions initiated by the application and the correlated stack traces
::umem_cache

    * Prints the details about each of the umem caches
[address]::umem_log

    * Prints the umem transaction log for the application
[address]::umem_verify

    * Prints the integrity of the umem caches which is useful in determining if a buffer has been corrupted

address$<bufctl_audit

    * Prints the contents of the umem_bufctl_audit structure as defined in the /usr/include/umem_impl.h header file

Example :

Traditional Memory Leak

In order to examine if SunMC has a memory leak, one can execute the following steps to narrow down the section of the code which is causing the leak.

1. The libumem library is only available on systems which are running the Solaris 9 OS, Update 3 and above.
%uname -a
SunOS hostname 5.9 Generic_112233-05

(csh)

2. Execute the application with the libumem library interposed and the appropriate debug flags set.
%(setenv UMEM_DEBUG default; setenv UMEM_LOGGING transaction;setenv LD_PRELOAD libumem.so.1; ./a.out)

(bash)

#UMEM_DEBUG=default;UMEM_LOGGING=transaction;LD_PRELOAD=libumem.so.1; ./a.out

3. Use the gcore (1) command to get an application core to analyze the application's memory transactions.

%ps -ef | grep esd
user1     970   714  0 10:42:42 pts/4    0:00 ./a.out

%gcore 970
gcore: core.970 dumped

4. Use MDB to analyze the core for memory leaks using the commands described in the previous section.

$mdb core.970
Loading modules: [ libumem.so.1 libc.so.1 ld.so.1 ]

> ::umem_log
CPU ADDR     BUFADDR         TIMESTAMP THREAD  
  0 0002e0c8 00055fb8     159d27e121a0 00000001
  0 0002e064 00055fb8     159d27e0fce8 00000001
  0 0002e000 00049fc0     159d27da1748 00000001
    00034904 00000000                0 00000000
    00034968 00000000                0 00000000
    ... snip ...
 
Here we can see that there have been three transactions by thread #1 on cpu #0.
 
> ::umalog

T-0.000000000  addr=55fb8  umem_alloc_32
         libumem.so.1`umem_cache_free+0x4c
         libumem.so.1`process_free+0x68
         libumem.so.1`free+0x38
         main+0x18
         _start+0x108

T-0.000009400  addr=55fb8  umem_alloc_32
         libumem.so.1`umem_cache_alloc+0x13c
         libumem.so.1`umem_alloc+0x44
         libumem.so.1`malloc+0x2c
         main+0x10
         _start+0x108

T-0.000461400  addr=49fc0  umem_alloc_24
         libumem.so.1`umem_cache_alloc+0x13c
         libumem.so.1`umem_alloc+0x44
         libumem.so.1`malloc+0x2c
         main+4
         _start+0x108
 The three transactions consist of one allocation to the 24 byte umem
cache, and one memory allocation and release from the 32 byte umem
cache. Note that the high resolution timestamp output in the upper left
hand corner is relative to the last memory transaction initiated by the
application.

> ::findleaks
CACHE     LEAKED   BUFCTL CALLER
0003d888       1 00050000 libumem.so.1`malloc+0x0
----------------------------------------------------------------------
 Total       1 buffer, 24 bytes

  This shows that there is one 24 byte buffer which has been leaked.

Thought it will be usefull for some new users of postgreSQl.
1.Create a Solaris OS user and group that will be used to administer PostgreSQL.
Note: PostgreSQL cannot be run as root user.
# groupadd postgres
# useradd -c 'PostgreSQL user' -d /export/home/postgres -g postgres -m -s /bin/bash postgres
2. The next step is to decide on a directory to create the database and ensure that the permissions are set correctly.
To use the default directory with the Solaris user called "postgres", execute the following commands to set the ownership and permissions:
# chown postgres /var/lib/pgsql/data
# chmod 700 /var/lib/pgsql/data
3. You are now ready to create a database.Login as "postgres" and execute the initdb command.
To create a database in /var/lib/pgsql/data, execute the following command:
$ initdb -D /var/lib/pgsql/data
4.PostgreSQL is now ready to be started using the following command:
$ pg_ctl -D /var/lib/pgsql/data -l postmaster.log start
or you can simply start
$ pg_ctl -D /var/lib/pgsql/data start
Or you can start the database server with
$postmaster -D /var/lib/pgsql/data
5.You can now test the running database.
To connect to a database called "postgres" running on a default port, execute the following command:
$ psql postgres
thats all and now you can use the database with all your SQL knowledge.
cheers

I was reading published paper by Hiroshi Yamauchi & Mario Wolczko at Sun Microsystems Laboratories.
"Writing Solaris Device Drivers in Java"
It is quite interesting to know there is an effort to port the JVM embedded in the Solaris kernel. There system is based on the Squawk virtual machine.The Squawk virtual machine core is mostly written in Java. It has an interpreter, and a just-in-time compiler. The lower-level parts and the main loop of the interpreter are written in C, while the more complex instructions (such as those dealing with monitors) are implemented in Java.
They have created and tested a RamDisk Device Driver written in Java.
They performed the following simple performance measurements to compare the Java version of the driver to the C version.
The measurements were performed on a Sun E420R system with four 450MHz UltraSPARC II CPUs and 1GB of RAM, using Solaris 10 (Build 76).
1. Raw system call overhead We measured the time to call the close system call on the RAM disk device. Because the close function of the RAM disk driver is empty, the measurement yields the total overhead from the system call down to the device driver routine and back. We repeated the measurement ten times and computed the average time. The Java version took 4.48 microseconds whereas the C version took 3.84 microseconds, an overhead of 16.7%. The virtual machine was given 512 KB of heap.
2. Throughput We measured the time to copy a 1MB file within the RAM disk. This measurement should indicate the performance of the block I/O of the driver. We repeated the measurement ten times and computed the average time. The Java version took 178 microseconds and the C version took 63 microseconds. When a GC occurred during a copy, the Java version took 230 microseconds. The Java version took approximately 2.8 times and 3.8 times longer than the C version without and with a GC, respectively. The virtual machine was given 512 KB of heap. We believe the overhead in the Java version is mainly due to bytecode interpretation. The results are encouraging because the Squawk virtual machine we used was an early unoptimized version,with a just-in-time compiler in development.
But what I see is if Java based device drivers are developed then the same driver can be used for both SPARC and X86 platform without modification provided the JVM is ported to both SPARC and x86.And may be if the JVM is ported to Linux then same driver can be used in linux too.
If you want to get the PDF file for the technical details then you can get it from
http://research.sun.com/techrep/2006/smli_tr-2006-156.pdf

The porpose of writing these docs are to educate the community about the real time aspect of Solaris Operating System.Step by Step I will try to write how we can use solaris for running realtime applications. Basic Rules of Real-time Applications. Real-time response is guaranteed when certain conditions are met. In This section I will discuss these conditions and some of the more significant design errors. Most of the potential problems described here can degrade the response time of the system. One of the potential problems can freeze a workstation. Other, more subtle,mistakes are priority inversion and system overload. A Solaris real-time process has the following characteristics: Runs in the RT scheduling class, as described in “The Real-Time Scheduler”. Locks down all the memory in its process address space. The Real-Time Scheduler Interface Calls That Control Scheduling Using priocntl Control over scheduling of active classes is done with priocntl(2). Class attributes are inherited through fork(2) and exec(2), along with scheduling parameters and permissions required for priority control. This inheritance happens with both the RT and the TS classes. priocntl(2) is the interface for specifying a real-time process, a set of processes, or a class to which the system call applies. priocntlset(2) also provides the more general interface for specifying an entire set of processes to which the system call applies. The command arguments of priocntl(2) can be one of: PC_GETCID,PC_GETCLINFO, PC_GETPARMS, or PC_SETPARMS. The real or effective ID of the calling process must match the real or effective ID of the affected processes, or must have superuser privilege. PC_GETCID This command takes the name field of a structure that contains a recognizable class name. The class ID and an array of class attribute data are returned. PC_GETCLINFO This command takes the ID field of a structure that contains a recognizable class identifier. The class name and an array of class attribute data are returned. PC_GETPARMS This command returns the scheduling class identifier or the class specific scheduling parameters of one of the specified processes.Even though idtype and id might specify a big set,PC_GETPARMS returns the parameter of only one process. The class selects the process. PC_SETPARMS This command sets the scheduling class or the class-specific scheduling parameters of the specified process or processes.

Please visit www.opensolaris.org to know more about open solaris.

Sun has long appreciated the importance of real-time applications. The Solaris Operating Environment was architected with a solid real-time foundation from its inception in 1987. In particular, Sun realized the power of combining both real-time and time-share capabilities in a volume, commercial off-the-shelf (COTS) operating system. This approach gives real-time systems access to extensive application availability, a flexible development environment for native real-time applications, and standards-based application portability.

Beyond these advantages, the Solaris Operating Environment allows real-time deployment systems to scale to meet increasing application demands. As computational load increases, additional processors can be added to the system for either time-share or real-time tasks — providing not only time-share, but real-time enterprise scalability. Systems can even be dynamically reconfigured to provide proportionally more dedicated, real-time computation resources on an as-needed basis.

No matter how attractive these advantages are, real-time applications have stringent timing requirements that must be taken into consideration in order for an operating system to be considered for deployment.
Tomorrow I will discuss the Real-time Programming and Administration in the Solaris™ Operating Environment.

Please visit the folowing URL to know more about Sun's Solution towards Sun Hardware and System Management.
Sun Management Center

What is SIP ?
Session Initiation Protocol(SIP).
SIP supports five facets of establishing and terminating multimedia communications:
a. User location: determination of the end system to be used for communication;
b. User capabilities: determination of the media and media parameters to be used for the session;
c. User availability: determination of the willingness of the called party to engage in communications;
d. Call set-up: "ringing", establishment of call parameters at both the called and calling parties;
e. Call handling: including transfer and termination of calls.
OpenSolaris SIP Stack and Library.
SIP Stack and SIP Library and its OpenSolaris Implementation.
Work to be done on OpenSolaris SIP Stack Library.

sipd: SIP proxy, redirect and registrar server based on opensolaris sip stack.

Other open source SIP implementations and porting it to opensolaris. i.e ser,Partysip

I got Blackbelt in 1993.I used to teach karate at Kendriya Vidyalaya Meenambakkam,Chennai,in the morning during my college days,for nearly three years.I represented Tamilnadu in the National Karate Championship at Trivandrum,1994.I was dreaming of participating in International level.But ....... There I saw the conditon of the National Champions in India,The government didn't support.We had to spend money from our pocket.No proper social acceptance,no support from Indian government,I was practicing for 4 long ours per day,but there I asked myself,do you really wanted to be like this ? The answer was no.So from there I lost my interst in Karate and I just practiced for my own and I left professional Karate.And now here I am.