Ozzie.eu

Blind ambition

This year's Imagine Cup second prize winner in Software Design was a group of students from Arizona State University.
Their project is a device to help taking notes for students with vision  disabilities.
The solution uses OneNote and is spotlighted in this inspiring short video:

Cloud Computing Data Center Architecture = Container

With the growing demand and adoption of cloud based Internet services, the computing performance of data centers has never been so demanding. This causes for the deployment unit for data centers to cease being on a server basis, or even a server farm basis, but hundreds of servers all in one container.

If the server stack of a service doesn't measure up to the performance standards required, scale with another container full of hardware.

Major players in cloud computing, Google and Microsoft are already defining their data center's architecture with this new order of greatness.

Google:
[youtube http://www.youtube.com/watch?v=zRwPSFpLX8I&w=560&h=349]
Microsoft:


All with a constant concern for energy-saving and the environment.

Tomboy sync using Windows and Ubuntu

For the eclectic folks like myself, that use multiple operating systems, synchronization tasks are always a challenge. The data to be synchronized has to be supported by a multi-platform client.

If we're talking about utilities like Dropbox, it already supports synchronization clients for windows, Mac and Linux.

On this specific case, I wanted a decent note taking application that allowed me to sync between my Windows desktop at work and my Ubuntu laptop at home. A suggestion I found on the Web worked on file based software and Dropbox synchronizing those folders. That might work, but

I found the solution with Gnome's desktop notes application, Tomboy. It's simple, supports sticky notes, search contents and linking between notes. Good enough for some personal stuff.

The first step, if you don't have such an account, is to register on Canonical's Ubuntu One service. It gives you 5GB free storage to sync files, contacts and notes on all your Ubuntu machines. It's meant to support Windows OS soon enough.

The second step is to install Tomboy on the Windows machine. To install Tomboy on Windows, you need .NET framework and gtk-sharp installed before you can install Tomboy:

• Get the .NET runtime


• Get the GTK# runtime


• Get Tomboy

After installing Tomboy, start the application. It automatically sets up an icon on the system tray. Press the right mouse button on it and choose "Preferences".

Go to the "Synchronization" tab and select the "Tomboy Web" service. Ont the server insert the following address: https://one.ubuntu.com/notes/

Choose the interval between synchronizations. press "Save" and you're all done on the Windows box. For the Ubuntu machine, there is this detailed tutorial on notes configuration on the Ubuntu One wiki pages.

Distributed Transactions on Windows 2008 Systems – III

This is the final post on a series dedicated to the MSDTC configuration on a Windows Server environment.

so far we've covered these aspects:

• Post I - How MSDTC works and relevant deployment scenarios and when do I need to perform additional configuration


• Post II - Defining a port range for MSDTC so it can be managed on a firewall configuration and enabling TCP/IP transaction communications.

Recalling the scenario for this post, we assume:

• static addressing of the hosts


• no naming servers available


• packet broadcast disabled


• firewall between application hosts and database hosts

On these conditions, MSDTC will not work because it cannot translate the NetBIOS names of the participating hosts into their IP addresses. Even without naming servers, DTC might try to resolve the hosts names with a network packet broadcast, but for the sake of this example we assume it's cut off by a firewall. Usually, even ICMP (ping) is cut off.

The remaining work around is to add address and name entries to a system file called "lmhosts". The "lmhosts" file is a local text file that maps Internet Protocol (IP) addresses to NetBIOS names of remote servers with which you want to communicate. It's similar to the regular "hosts" file but the latter one concerns general network lookup, like DNS replacement. The Lmhosts file is located in the "%SystemRoot%\System32\Drivers\Etc".

So, the first step is to edit the "lmhosts" file and add entries for each of the remote hosts involved. It's done adding a tab separated pair of IP address and NetBIOS name on each line. You can add the #PRE suffix to the lines so the host loads the lookups at boot time. For instance:

10.0.132.73 remote-mssql-host-1 #PRE
10.0.132.65 remote-mssql-host-2 #PRE

Afterwards, the TCP/IP connection properties need to be edited:

• On the Windows host, open the Network and Sharing Center. Press the "Local Area Connection" link.

• Press the "Properties" button. On the new window select the "Internet Protocol Version 4" and press "Properties".

• Press the "Advanced" button and select the WINS tab. Choose to enable LMHOSTS lookup and NetBIOS over TCP/IP.

Press "OK" on all windows. Perform these steps, together with the ones mentioned on the previous posts and try your luck.

Hope this helps.

Windows 7 God Mode

If you use Windows 7, create a new folder on your Desktop and name it "GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}". Open it to see the numerous options it gives you: administrative tools, backup and restore options, security settings.

It's a nice feature to perform super user tasks.

Distributed Transactions on Windows 2008 Systems – II

Following the subject of this here previous post, I'll discuss here a possible configuration process for DHCP reliant networks, with firewalls between segments.

The Windows Distributed Transaction Coordinator performs its communication using RPC communication, which by default means it requires 135 port and a set of dynamic ports above 1024.

A dynamic set of ports with no well-known range is not a best practice for network security. Given that, it's not a question of just asking the firewall administrator to open the default ports. We'll first configure a port range on the DTC service of the target machines.

On one of the hosts to configure:

• open the Windows Menu > Administrative Tools > Component Services;


• Drill-down to "My Computer", then select "Properties" from the mouse context menu;

• Select the "Default Protocols" tab. There should be a "Connection Oriented TCP/IP" item; Press the "Properties" button.

• Press the "Add" button and type in a suitable range like "50000-50200". This means DTC will use RPC thru ports 50000 to 50200.

Press OK on all windows and restart the server to assure it assumes the newly configured range.

Please note that this configuration has to be done on ALL hosts participating on the distributed transaction. If a given scenario has two separate MSSQL Server hosts and two more application servers, all four machines must have the port range configured on the DTC service configuration.

This step configured the port range for MSDTC on the target hosts. The next step is to request the firewall administrator to open the following ports between the two networks:

• 135: fixed standard port for RPC


• 50000-50200: the range we configured on the example. Could be another given range.

Besides the network firewalls, each hosts own Windows firewall configuration must be edited to allow the connections thru the newly configured port range. To do this, on each host, open the "Windows Firewall with Advanced Security" utility. If hints on that are needed, there's this article on Technet.

Talking about distributed transactions over the network, it's obvious TCP/IP communications ar involved. Consequently, this channel has to be enabled on the local DTC.

1. open the Windows Menu > Administrative Tools > Component Services;


2. Drill-down to “My Computer \ Distributed Transaction Coordinator \ Local DTC”, then select “Properties” from the mouse context menu;


3. Select the “Security” tab. The following options need to be checked: Network DTC Access, Allow Remote Clients, Allow Remote Administration


4. Still on the same window, on the Transaction Manager Communication: Allow Inbound, Allow Outbound, No Authentication Required


5. Check the Enable XA Transactions, uncheck the SNA LU option if you're no using legacy systems.

Press OK on all windows. It should be all done. This scenario still relies on dynamically assigned IP addresses and windows network architecture with WINS servers.

On the next and final post of the series, I'll consider a worst case scenario:

• static addressing of the hosts


• no naming servers available


• packet broadcast disabled


• firewall between application hosts and database hosts

It should be relatively interesting since everything is configured manually and it's a not so uncommon scenario for highly secured, tightly managed networks.

Distributed Transactions on Windows 2008 Systems - I

When using distributed transactions between distinct databases, using Microsoft Windows technology, one relies on the MSDTC - Microsoft Distributed Transaction Coordinator.

The main catch to this distributed architecture is that it works based on the hosts NetBIOS names, which is specific to the Windows operating systems and is used for network resource sharing and the like.

There are at least four relevant deployment scenarios concerning this technology:

1. Full stack on the same physical host


2. DHCP reliant network, all hosts on the same segment


3. DHCP reliant networks, with firewalls between segments


4. Static Address network with firewalls

The first scenario, full stack, isn't challenging because it assumes you have the Application Server and Databases all in the same machine. It can be imagined as the common scenario for developer machines which often have the IDE, DB Server and App Server all-in-one.

The second scenario where all hosts reside on the same network segment, usually a net mask of 255.255.255.0, requires only additional configuration if there are no WINS server available and network broadcast of packages has been disabled. Otherwise the default configuration will work fine.

Next post will discuss a configuration scenario with a firewall in between the Application Server and the Database Server.