TechNote: Install LogMeIn Hamachi on Linux

TechNote: Install LogMeIn Hamachi on Linux Technology Operating System(s): Linux Technology(ies): Hamachi Use Case(s): VPN Summary Hamachi for Linux is a secure VPN client for Linux platforms, offering connectivity from dispersed environments to your resources. The follow provides a high level view of how to install the Hamachi on a Linux system. Detail Following these steps, and adjusting for your specific distribution, will result in Hamachi being installed: RHEL/CentOS: When installing Hamachi on a RHEL/CentOS system you will need the redhat-lsb package installed. You can install this package using 'yum'.      # yum install redhat-lsb Step 1: Install Hamachi      32-bit:      # wget https://secure.logmein.com/labs/logmein-hamachi-2.1.0.139-1.i486.rpm      # rpm -ivh logmein-hamachi-2.1.0.139-1.i486.rpm      # /etc/init.d/logmein-hamachi start      64-bit:      # wget https://secure.logmein.com/labs/logmein-hamachi-2.1.0.139-1.x86_64.rpm      # rpm -ivh logmein-hamachi-2.1.0.139-1.x86_64.rpm      # /etc/init.d/logmein-hamachi start Step 2: Joint An Existing Network      # hamachi login      # hamachi join 111-222-333     (where 111-222-333 is the network id you wish to join) Step 3: Verify Status      # hamachi http://crunchbang.org/forums/viewtopic.php?id=29228

TechNote: Converting a Virtual Hard Disk -- OVA to VHD

TechNote: Convert a Virtual Hard Disk -- OVA to VHD Technology Operating System(s): Windows Technology(ies): Hyper-V Use Case(s): Virtualization Summary Overview

An Open Virtual Appliance (OVA) file is a archive of an Open Virtualization Format (OVF) package. These files can be converted for use with Hyper-V by following these steps:

1. Extract: Using 7-Zip extract the convents of the OVA file
   
   You should get an OVF file, and a VMDK file as a result of the extract.
   
2. Convert: Using the VBoxManage.exe utility that comes with VitualBox type the following command:
   
   C:> VBoxManage clonehd --format vhd disk1.vmdk disk1.vhd
   
   This will create a VHD file from the VMDK file.
3. Copy: Place the VHD file in an appropriate location.
   
4. Create: Using Hyper-V Manager you can Create a "New" > "Virtual Machine..." using the VHD file as an "existing virtual hard disk".

This process should result in you having a virtual image that is equvilent to the OVA you started with.

DevNote: Android Service

DevNote: Android Service
Technology
	Operating System(s): Android Technology(ies): Android Service Use Case(s): Software Development
Summary
	Overview Services are Android application components representing either an application's desire to perform longer-running operations while not interacting with the user or to supply functionality for other applications to use. Each service class must have a corresponding <service> declaration in its package's AndroidManifest.xml file. Services can be started with Context.startService() and Context.bindService(). Note that services, like other application objects, run in the main thread of their hosting process. This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work. More information on this can be found in Processes and Threads. The IntentService class is available as a standard implementation of Service that has its own thread where it schedules its work to be done. Service Lifecycle No matter how many times a service is started, it will be stopped once Context.stopService() or stopSelf() is called; however, services can use their stopSelf(int) method to ensure the service is not stopped until started intents have been processed. For started services, there are two additional major modes of operation they can decide to run in, depending on the value they return from onStartCommand(); START_STICKY is used for services that are explicitly started and stopped as needed, while START_NOT_STICKY or START_REDELIVER_INTENT are used for services that should only remain running while processing any commands sent to them. Clients can also use Context.bindService() to obtain a persistent connection to a service. This will also creates the service if it is not already running (calling onCreate() while doing so), but does not call onStartCommand(). The OS will keep a service running as long as it is started, or there are connections to it with the Context.BIND_AUTO_CREATE flag. Once neither of these situations holds true, the service's onDestroy() method is called and the service is effectively terminated. There is some confusion surrounding the Service class and what it is not: A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of. A Service is not a thread. It is not a means itself to do work off of the main thread. A Service itself is actually very simple, providing two main features: A facility for the application to tell the system about something it wants to be doing in the background. This corresponds to calls to Context.startService(), which ask the system to schedule work for the service, to be run until the service or someone else explicitly stop it. A facility for an application to expose some of its functionality to other applications. This corresponds to calls to Context.bindService(), which allows a long-standing connection to be made to the service in order to interact with it. When a Service component is actually created all that the system actually does is instantiate the component and call its onCreate() method and any other appropriate callbacks on the main thread. It is the responsibility of the Service class to implement the appropriate behavior; such as creating a secondary thread in which it does its work. Reference Android Developers | Service
Description
	Code It is possible to run a service always. To accomplish this: In the service onStartCommand() method return START_STICKY. public int onStartCommand(Intent intent, int flags, int startId) {     return START_STICKY; } Start the service in the background using startService(MyService) so that it always stays active regardless of the number of bound clients. Intent intent = new Intent(this, PowerMeterService.class); startService(intent); Create the binder. public class MyBinder extends Binder {     public MyService getService() {         return MyService.this;     } } Define the service connection. private ServiceConnection m_serviceConnection = new ServiceConnection() {     public void onServiceConnected(ComponentName className, IBinder service) {         m_service = ((MyService.MyBinder)service).getService();     }     public void onServiceDisconnected(ComponentName className) {         m_service = null;     } }; Bind the service using bindService(). Intent intent = new Intent(this, MyService.class); bindService(intent, m_serviceConnection, BIND_AUTO_CREATE); For your service you may want a notification to launch the appropriate activity once it has been closed. private void addNotification() {     //----- Create The Notification -----     Notification.Builder m_notificationBuilder = new Notification.Builder(this)         .setContentTitle(getText(R.string.service_name))         .setContentText(getResources().getText(R.string.service_status_monitor))         .setSmallIcon(R.drawable.notification_small_icon);     //----- Create The Pending Intent And Add To The Notification -----     Intent intent = new Intent(this, MyService.class);     PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, intent, 0);     m_notificationBuilder.setContentIntent(pendingIntent);     //----- Send The Notification -----     m_notificationManager.notify(NOTIFICATION_ID, m_notificationBuilder.build()); } Modify the AndroidManifest.xml file to launch the activity in single top mode. android:launchMode="singleTop" The "standard" and "singleTop" modes differ from each other in just one respect: Every time there's new intent for a "standard" activity, a new instance of the class is created to respond to that intent. Each instance handles a single intent. Similarly, a new instance of a "singleTop" activity may also be created to handle a new intent. However, if the target task already has an existing instance of the activity at the top of its stack, that instance will receive the new intent — in an onNewIntent() call — and a new instance is not created. In other circumstances — for example, if an existing instance of the "singleTop" activity is in the target task, but not at the top of the stack, or if it's at the top of a stack, but not in the target task — a new instance would be created and pushed on the stack. Note that if the system needs the resources and your service is not very active it may be killed. If this is unacceptable bring the service to the foreground using startForeground(). startForeground(NOTIFICATION_ID, m_notificationBuilder.build()); The service may be killed by the OS on occasion but it will be restarted automatically because the START_STICKY constant was returned from onStartCommand(). The START_STICKY constant tells the OS that if the service process is killed while it is running, then leave it in the started state but don't retain the delivered intent.
Notes / Considerations
	.

TechNote: Restart RDP (Remote Desktop Protocol)

TechNote: Restart RDP
Technology
	Operating System(s): Windows Server 2008+ Windows 7+ Technology(ies): Microsoft RDP Use Case(s): System Administration
Summary
	Periodically RDP access to a remote host can become inoperable. One solution is to restart the offending system; and in the case of virtual machines (VMs) you may be able to access the system using the VM Manager. This solution may provide an option that if fast and friendly.
Description
	Remote Command Line: sc \\{ServerName} queryex UmRdpService taskkill /s \\{ServerName} /pid {PID}  (it may necessary to force with /f option) sc \\{ServerName} queryex TermService taskkill /s \\{ServerName} /pid {PID} (it may necessary to force with /f option) sc \\{ServerName} start TermService Local Command Line: sc queryex UmRdpService taskkill /pid {PID} (it may necessary to force with /f option) sc queryex TermService taskkill /pid {PID} (it may necessary to force with /f option) sc \\{ServerName} start TermService
Notes / Considerations
	WARNING: DO NOT try this on a production system without first testing it to ensure the results are what you expect.

Organizational Dynamics and Group Think

There are many terms that have become common in "Corporate America" today;

• Nothing Personal...It's Just Business
• Servant Leadership
• We Owe It To Our Investors/Owners
• Our Employees Make The Difference
• Customer Service

Some of these terms are completely valid and appropriate, but others fall short of being productive to an organization or to humanity at large. One of the terms that has I personally have come to dislike is "Nothing Personal...It's Just Business". Those who use the term have completely forgotten or never understand that business is completely and absolutely about relationships. Relationships with your customers. Relationships with your employees. Relationships with your partners. Relationships with your community. The best businesses work to ensure that all of these relationships are a win-win.

Over the years I have had a chance to talk to many people about this very thing, and individually most agree. But I have also seen those same individuals, in the light of corporate oversight, act counter to the philosophies for which they personally agree. This to a substantial degree comes from a number of dynamics that we start to experience from an early age; peer pressure, group think, and fear.

These dynamics all play into how an organization responses to moral and ethical questions. Before going on there is a statement that I used in my last blog post, and have used in various forms over the years.

The right thing to do remains so even in adversity.

Basically what I am trying to impart with the statement is that sometimes we as individuals take a path that isn't "righteous" because it isn't in alignment with company policy, won't help us get that promotion, might cost us our job, or even causes us to exceed our corporate budget. But when we yield to these types of pressures what is the net result? At a minimum we diminish ourselves, but more likely, and importantly, we impact others adversely.

Great leaders overcome great obstacles to ensure that the GREATER good is served and not purely that the bottom line is improved.

Character vs Reputation

Recently I have had a number of conversations with people surrounding the following:

“Be more concerned with your character than your reputation, because your character is what you really are, while your reputation is merely what others think you are.” - John Wooden

The reactions to the statement are mixed. Some think that reputation (the perception that others have about you) is very important, while some believe that perception is overrated. Is there a difference between the two?

From my point of view character is the more important. Your character, or core beliefs, dictate how you act  and those visible actions will result in a reputation. It is very possible that individuals without a full understanding of a situation will have a negative perception of you and/or your actions, but in the end that is really a battle for them to resolve.

I submit to you that:

To remain righteous an individual must do the right thing, without regard for what others will think or how they will respond. To that end…The right thing to do remains so even in adversity.

In the end we are the sum of what we have done and what we have failed to do.

Data Modeling...Immutable Data

Recently I had an email dialog with a colleague that I have a great deal of respect for. The general topic was on accessing data within a database by know/constant values. Basically we needed to retrieve data from a table with one value, and cross reference it to a second value.

Everyone is thinking, "Okay...What's the big deal? We do that every day.", and I agree. At first blush this is something software developers do all of the time. But in this specific case the lookup value was going to be persisted within XML, and at the same time the persisted value is visible to end-users. One more point. Within our system there is no place that the end-user can change the lookup value, they can only see it. We want the lookup value to be immutable because there is no way to ensure that if one of the values changes, we will remember to change the other. The end-user cannot change it, and the software application don’t change it.

So let’s get to the point.

Immutable data is information within a file, table, or program that is "unchangeable". Given my description of the system above you should agree that the value in question is immutable. Right?

Well I think there is one more rule that needs to be applied to the definition of immutable when working with software systems; The end-user cannot see it.

"How does an end-user having read-only access to a data element impact immutability?" you should ask. Directly...If end-users can see something, they will eventually ask for that thing to be changed. Right? Right. That is one of the natural laws, and if it isn't it should be.

As soon as we introduce the human factor into the equation things get a little soft. Once upon a time many of us believed that things like usernames, credit card numbers, and policy numbers where immutable from a software systems perspective. That is until a person gets re-married, or their account number has three sixes within it, or they have an unlucky number that appears in their policy number. Whatever the reason, data immutability is directly related to viability. Period. Don't fool yourself otherwise.

I have a general rule...System values can only remain system values if they are only visible to the system. At the same time, users should never be restricted from changing their username, because we as software developers have used it in a "special way".

So in summary, here is my definition of "immutable" from a software systems design perspective:
---

Definition: Immutable - im·mu·ta·ble [ih-myoo-tuh-buhl] 

- adjective
Information contained within a software system that is never changed, can never be changed, and is never visible to end-users of the system.