Happy New Year! As you may have noticed, it's 2010, and we haven't yet shipped the project we referred to last year as "Viewer 2009". We made the decision to delay for a very good reason: It wasn't up to our standards of quality and user experience, and we simply needed more time to make it better.
A project the size of Viewer 2 (as it's now called) is a new thing for us at the Lab. We've not done much at this scale before and we've made some substantial changes to how we work in order to pull it off. Here's a bit of the back story on what we've been up to and what's coming soon.Focus on the New User and First Hour ExperienceHere's a sobering statistic: Over 50% of new Residents who register and download the Second Life viewer log in once and never come back a second time. We've made it way too hard for a new user to absorb all the wonderfulness that is Second Life.With Viewer 2, our revamped web site, a new Orientation Island and much more, we've taken a step back and tried to create an end-to-end experience that will be much more compelling and relevant for a new Resident. There's still more to do, but we believe we've made a pretty dramatic step forward.But what about existing Residents?When Viewer 2 ships, some current Residents will find it frustrating. While we have kept almost all existing functionality, the UI has changed dramatically. It looks different. Menus have moved. There are new ways of interacting and communicating. If you've come to know and love the existing user interface, it may be a challenging transition.Other Residents will embrace the new UI. It is more consistent and discoverable. The look is more polished and professional. Our UI team, along with our outside design partners 80/20 Studio took a fresh look at the entire interface, with the goal of making Second Life more immediately relevant and compelling. We worked very closely with a core set of Residents to make sure that we were making design choices that would enhance the experience. Sometimes we got it exactly right and sometimes they sent us back to the drawing board. We also did several rounds of formal usability testing with both new users and existing Residents. We took all of this feedback to heart and it helped us make Viewer 2 even better.The current viewer, version 1.23, will not go away any time soon. In the earliest case, following the policy T described here, 1.23 will be around until 30 days after we ship Viewer 2.1 (our first update to the new viewer), about a quarter after delivery of Viewer 2. Even then, there will continue to be open source viewers based on the 1.23 code base available for users who wish to continue using them.Open Source is a Big DealLike previous viewers, Viewer 2 will be released to open source. We've got a bit of work to do to rebase Snowglobe off of the Viewer 2 code base and merge in Snowglobe changes, but we're on it.Open Source is a big deal for us. What the adoption of open source viewers has made clear is that many Residents want a high-end "power user" experience. We know we can't do it all. We can't at the same time work towards expanding our user base to a broader, consumer market and address all of the needs of our high-end Residents. We need help from our robust, passionate developer community to develop "power user" and more niche market viewers.Of course, there are lots of other great reasons for our Open Source efforts, but they are beyond the scope of this note. For example, we're working with the Internet Engineering Task Force (IETF) to establish broad standards for virtual worlds, starting with formal definitions of the region and agent domains, a.k.a. VWRAP. Open Source is a key tenet of this work.We've stepped up our Open Source efforts and will continue to support the development community as best we can. For example, we've been meeting regularly with the Emerald team and are supportive of their development of a viewer that meets the needs of many long-time Residents.We're also keenly aware that a few bad actors are using open source viewer code to create viewers that enable functionality that violates our terms of service or enables intellectual property theft. As Cyn describes here, with our Third Party Viewer Policy our intent is to list viewers that comply with new guidelines and policies so that Residents can make informed choices about which viewer to use. At the same time, we will be taking aggressive action against developers that don't comply with these guidelines.New Ways of Working == Better SoftwareIf you're a software development geek, you might be interested to know that we're in the thick of a substantial transition in how we build software. Most of our teams have moved to a Scrum-inspired model, keeping iterations short, quality high and working off of a clearly prioritized product backlog.We've also built a new test automation team, and are building an automated test suite to help catch performance and functional regressions before they make it to Residents. Our automated "Crash Reporter" helps us find and fix all but the most obscure crashers. If we've done our jobs well (and I think we have), Viewer 2 should be the most stable SL Viewer ever. We've got lots more to do and you'll continue to see even more stable software, more regular updates, and fewer regressions. In other words, our goal is to deliver software that Just Works.Coming Soon: Viewer 2 Public BetaWe're still putting the finishing touches on Viewer 2 and will be pulling the covers off very soon -- we hope in February. Watch this blog for an announcement. Of course, Viewer 2 is just the beginning, not the end. There is much more to do. Our plan is for Viewers 2.1 and 2.2 to follow along in much shorter order than it took to get Viewer 2 out the door. We're currently targeting quarterly high-quality releases, and with the changes we've made to how we build software, we've got a very good shot of achieving that goal.Did we get it all right with Viewer 2? No. Is it a substantial leap forward in the discoverability and usability of our Viewer? Yes, I think it is. And I hope you will too. Stay tuned...

If you are in a small business or a larger enterprise you know you need to keep track of all those machines. Sure you could easily tag and record them as they go from the box to the desk, but that doesn’t always happen. And the larger the company the more likely something is able to get by you without you getting a complete record of the system. If that is the case you need some tool to help you ascertain what you have out there. Add to that the idea that we are more and more living in a homogeneous IT world, where more than one operating system might be living on your network.

Having a tool that can quickly, and regularly, take snapshots of your network landscape is critical to keeping tabs on your PCs. Of course you can shell out some budget dollars for a proprietary tool, but why bother when you can fire up a Linux machine and use the trusty Nmap tool for the job.

Nmap is a command line tool that rapidly scans a network gathering information about machines and ports. It is easy to use and flexible, making it perfect for the job of asset scanning. In this tutorial you will see how to set up a system that will regularly scan your network and create a report that can then be used to keep inventory of your networked machines.

Installing

Before we get to the actual scanning we need to install a couple of applications. Since I am using a Ubuntu system, we’ll run the installation using apt-get. With some simple modifications, you can do the same on a fedora system. The two applications to install are: nmap and ndiff. We use ndiff to compare the results of scans. To install these applications open up a terminal window and issue the following command:

sudo apt-get install nmap ndiff

You will have to accept dependencies, at which point the two applications will install. Upon completion of the installation, you are ready to scan.

Using nmap

Nmap is actually a fairly powerful tool. If you issue the command man nmap you will see just how powerful this tool is. You can also see how many arguments you can use with Nmap as well as what each argument does. Fortunately I will show you a simple command you can issue to make this a bit easier.

I am going to illustrate how these tools work together by running an nmap scan on a small internal network. I will then scan the network after making a change to one machine and see if ndiff catches the change.

The command for the scan is:

sudo nmap -n -PN 192.168.1.1/24 -O > network_scan

I will then run that same scan after making the change with one alteration:

sudo nmap -n -PN 192.168.1.1/24 -O > network2_scan


The above commands will output to the files network_scan, and network2_scan.

Once you have the two files you will compare them using the ndiff command like so:

ndiff -b network_scan -o network2_scan

The two options used are:

b – Baseline.
o – Observed.

You can think of Baseline as your control group.

Figure 1

The results of the command are shown in Figure 1.

The results show exactly what occurred in my network change. I shut down the machine associated with IP address 192.168.1.37.

Of course you could also get a much clearer picture of your network by combing through the results of the initial scan, but if you are looking for how your network topography has changed from scan to scan, using ndiff is the best way.

To see the full usage of both nmap and ndiff, take a look at the man pages. I will warn you, they are fairly complex. But this tutorial should give you a solid understanding of how the basics of the tools work.

Tags: asset management, ndiff, network scans, nmap, port scanning

Related posts

Port Scanning Networking Tool SuperScan (1)
Map your network with Zenmap (1)

If you run any sort of server that is accessible by the public, you know the importance of certificate authorities (CAs). These certificates give your users a bit of insurance that your site is actually what it claims to be and not a spoofed version of your site waiting to either snag some data or drop a small payload onto an unsuspecting users’s machine.

The problem with CAs is that they can be a bit costly – especially for the administrator running a free service, or even a small business without the budget for purchasing CAs. Fortunately you don’t have to shell out the money for CAs, because you can create them for free on your Linux machine with an easy to use application called TinyCA.

Features

Create as many CAs and sub-CAs as you need.
Creation and revocation of x509 S/MIME certificates.
PKCS#10 requests can be imported and signed.
Both server and client CAs can be exported in multiple formats.

TinyCA works as a user-friendly front-end for openssl, so you don’t have to issue all of the necessary commands to create and manage your CAs.

Installing TinyCA

You won’t find TinyCA in your distribution’s repositories. You can either add the necessary repository to your /etc/apt/sources.list file or you can install from one of the binaries found on the main page. Let’s use Ubuntu and Debian as an example for installation.

If you want to install using apt-get you will need to first add the repository file to your sources.list file.  So open up the /etc/apt/sources.list file with your favorite editor and add the following line:
deb http://ftp.de.debian.org/debian sid main

NOTE: Replace “sid” with the version you are using. If you are using Ubuntu 9.04 the example above will work.

Now run the command:

sudo apt-get update

You will notice that apt-get complains about the lack of a gpg key. That’s okay because we are going to install using the command line. Now issue the command:

sudo apt-get install tinyca

This should install TinyCA without complaint. You might have to okay the installation of some dependencies.

Using TinyCA

Figure 1

To run TinyCA issue the command tinyca2 and the main window will open. Upon your first run you will be greeted by the Create CA window (see Figure 1). When you already have CAs this window will not open automatically. In this window you will create a new CA.

Figure 2

The information you have to enter should be fairly apparent as well as unique to your needs. After you fill out the information click OK which will open up a new window (see Figure 2). This new window will contain configurations that are passed onto SSL during the creation of the certificate. Like the first window, these configurations will be unique to your needs.

After you fill this information out click the OK button and the CA will be created. Depending on the speed of your machine, the process could take a bit of time. Most likely the process will be completed within 30-60 seconds.

Managing your CAs

Figure 3

When your CA is complete you will be taken back to the management window (see Figure 3). In this window you can create SubCAs for your main CA, you can import CAs, open CAs, create new CAs, and (most importantly) export CAs. You can’t see the Export button in Figure 3, but if you were to click the down arrow on the upper right portion of the window you would see another button you can click to export a CA.

Of course you have just created a Root Certificate. This certificate will only be used for:

create new sub-CA:s
revoke sub-CA:s
renew sub-CA:s
export the root-CA:s certificate

For anything other than the above you would want to create a SubCA. We’ll discuss creating a SubCA that can actually be used for your website in the next article.

Final thoughts

TinyCA takes a lot of work out of the creation and management of certificate authorities. For anyone that manages more than one web site or server, this tool is certainly a must have.

Tags: CAs, certificate authority, server security, SubCAs, web server security

Related posts

No related posts.