The secrets of Node's success
june 2011 by cloudseer
Sections
Browser wars and JavaScript performance
The rehabilitation of JavaScript
Node.js solves a real problem
Evented I/O
Sharing code between the browser and server
Critical mass for Node.js
Node is not the "next" anything
In the short time since its initial release in late 2009, Node.js has captured the interest of thousands of experienced developers, grown a package manager and a corpus of interesting modules and applications, and even spawned a number of startups.
What is it about this technology that makes it interesting to developers? And why has it succeeded while other server-side JavaScript implementations linger in obscurity or fail altogether?
The key factors are performance, timing, and focusing on a real problem that wasn't easily solved with other server-side dynamic languages.
Browser wars and JavaScript performance
In the early 2000s, AJAX web development was coming into its own and placing increasing demands on browsers' JavaScript engines. New JavaScript libraries such as YUI, Dojo and jQuery were allowing developers to do much more with web user interface (UI), creating a user experience for web applications that mimicked the behavior of desktop applications.
As JavaScript libraries and websites became more complex and users started to notice poor performance in their browsers, browser developers started to focus seriously on their JavaScript engines.
The race for faster JavaScript engines heated up in September 2008 when Google released Chrome and the Chromium source code. The engine behind it was V8 and it outperformed all others. This helped spur the developers of Firefox, Safari, Opera and Internet Explorer to improve JavaScript performance in their browsers and it opened a new front in the browser wars.
Technically speaking, V8 takes a slightly novel approach to improving performance. Certain JavaScript objects are dynamically compiled directly into native machine code before execution based on a predictive analysis of the code.
This, along with a new approach to property access and a more efficient garbage collection system enabled Chrome to initially post significantly faster benchmarks than other browsers.
Save 50% - JavaScript Ebooks and Videos
JavaScript is everywhere: servers, rich web client libraries, HTML5, databases, even JavaScript-based languages. If you've avoided JavaScript, this is the year to learn it. And if you don't, you risk being left behind. Whatever your level, we have you covered:
Introductory / Intermediate / Advanced
One week only—offer expires 14 June. Use discount code HALFD in the shopping cart. Buy now and SAVE.
The other browsers responded with improved or completely rewritten JavaScript engines that matched or exceeded V8's benchmarks. These optimizations are still going on, and Google's V8 is benefiting from the healthy, often technically brilliant, competition. Compared to the interpreters for server-side dynamic languages like Ruby, Python, PHP and Perl, JavaScript now has several efficient and incredibly fast runtimes.
Ryan Dahl, creator of Node.js, chose the V8 engine for Node. This has an additional benefit for a server-side implementation.
The predictive optimization of JavaScript works fairly well in the Chrome browser, but it is much more effective for server applications where the same chunks of code tend to be run multiple times. V8 is able to refine its optimizations and soon ends up with very efficient cached machine code.
Node has an additional performance advantage (a big one) that is not directly tied to V8, but we'll get to that in a bit.
The rehabilitation of JavaScript
JavaScript was once widely regarded as an awful hack of a language. Many programmers still feel this way, but the prejudice is starting to fade, mostly because there is a growing body of good code that shows off the language.
One person who has done much to pinpoint JavaScript's technical weak points is Douglas Crockford. Fortunately, instead of stopping there, he has also created JSLint and written "JavaScript: The Good Parts" to help developers write better code while avoiding most of the "bad parts" of the language. In his presentations and posts, one of his core assertions is that:
... despite JavaScript's astonishing shortcomings, deep down, in its
core, it got something very right. When you peel away the cruft, there
is an expressive and powerful programming language there. That
language is being used well in many Ajax libraries to manage and
augment the DOM, producing an application platform for interactive
applications delivered as web pages. Ajax has become popular because
JavaScript works. It works surprisingly well.
Without getting into the details of which parts are good or bad, we have seen in the past few years that professional developers have come to realize that JavaScript is not going away. Many of developers have gotten on with the task of building complex, well-designed applications and libraries. There are still problems with JavaScript and with its specification, but programmers are now much less likely to dismiss it out of hand.
Previous server-side JavaScript frameworks had a much harder time overcoming the negative mindset about the language. By the time Node arrived, JavaScript had overcome the most of its image problem.
Node.js solves a real problem
Wikipedia has a fairly comprehensive "Comparison of server-side JavaScript solutions". Node is in there, but most of the others listed are not nearly so well known. The use of the term "solutions" is interesting, as most of these projects are solutions to problems that have already been solved by other languages.
Python, Java, Ruby, PHP, Perl and others are all still extremely good choices for most types of dynamic web applications. They talk to databases, crunch numbers, validate data, and parse templates. They are high-level languages, and there are several MVC frameworks for each of them for quick web app creation. Node is sometimes touted as the next Ruby-on-Rails, but this a bad comparison and misses the point of what Node is for.
Node is not trying to solve the same problems as Rails, and it's not competing head-on with any of the other languages or frameworks in the areas where they do well. It was made for, and is most successful at, solving a special set of problems with modern web applications. What can it do that these other languages cannot?
It turns out that what JavaScript can do is the flip side of something it can't do: blocking I/O.
Evented I/O
JavaScript itself can't actually read or write to the filesystem. This ability was omitted from the language because it wasn't necessary for its job in the browser, so Node was able to start from scratch with an I/O system based on event loops.
Node is all about "evented I/O," but what does that actually mean?
To those of us who are either not programmers or are not familiar with event loops, an analogy might help.
You're in a grocery store with a list of items to buy. You wheel your cart around the store, pick up one item at a time, put it in your cart, then take the cart through the checkout. You can optimize this slightly by fetching the items in a sane order, but you can't go get the milk while you're waiting at the deli counter.
If you're in a hurry, you might start thinking of crazy ways to speed up the process. You could enlist a number of other shoppers with shopping carts and send each out to buy a single item. This would create bottlenecks in narrow isles and a huge traffic jam at the checkout
This is clearly an insane way to solve the issue because it throws more shopping carts and cash registers at the problem than needed.
Programming languages that block on I/O often try to solve similar problems by spawning additional threads or processes (c.f. Apache, sendmail). This can be expensive in terms of memory usage, and an analysis of Python's Global Interpreter Lock shows just how expensive the traffic jam can be in terms of CPU utilization.
JavaScript and Node use event loops and callbacks to approach the problem differently.
Returning to the shopping example: If you had a group of kids along with you on your shopping trip, you could send each off to get a single item and return them to the cart. When they've all returned, you can proceed through the checkout. The time taken in fetching items would be the maximum time for retrieving a single item (the kid who had to wait at the deli counter), rather than the sum (picking up the items in sequence). Using runners for the small, simple task of fetching items is a more efficient way of parallelizing the problem than sending out full-fledged shoppers and carts.
It's not a perfect analogy by any means, but more succinct and accurate descriptions involve code or pseudo-code. Ryan Dahl's initial presentation at JSConf 2009 used the following example:
var result = db.query("select..");
// use result
Here the database query blocks the program from doing anything else until the query is returned, whereas in an event loop:
db.query("select..", function (result) {
// use result
});
... the program can continue doing things while waiting for the function to call provide its callback.
Node provides non-blocking libraries for database, file and network access. Since I/O is not a fundamental part of JavaScript, nothing had to be taken away to add them. Python's Twisted and Ruby's Event Machine have to work around some basic language components in order to get similar evented behavior.
So, in addition to the performance wins Node gets "for free" by using the V8 JavaScript engine, the event loop model itself allows Node servers to handle massive concurrencies in network connections very efficiently. It often approaches the benchmarks achieved by high-performance reverse proxies like Nginx (which is also based on an event loop).
Sh[…]
Programming
javascript
nodejs
server
shared
from google
Browser wars and JavaScript performance
The rehabilitation of JavaScript
Node.js solves a real problem
Evented I/O
Sharing code between the browser and server
Critical mass for Node.js
Node is not the "next" anything
In the short time since its initial release in late 2009, Node.js has captured the interest of thousands of experienced developers, grown a package manager and a corpus of interesting modules and applications, and even spawned a number of startups.
What is it about this technology that makes it interesting to developers? And why has it succeeded while other server-side JavaScript implementations linger in obscurity or fail altogether?
The key factors are performance, timing, and focusing on a real problem that wasn't easily solved with other server-side dynamic languages.
Browser wars and JavaScript performance
In the early 2000s, AJAX web development was coming into its own and placing increasing demands on browsers' JavaScript engines. New JavaScript libraries such as YUI, Dojo and jQuery were allowing developers to do much more with web user interface (UI), creating a user experience for web applications that mimicked the behavior of desktop applications.
As JavaScript libraries and websites became more complex and users started to notice poor performance in their browsers, browser developers started to focus seriously on their JavaScript engines.
The race for faster JavaScript engines heated up in September 2008 when Google released Chrome and the Chromium source code. The engine behind it was V8 and it outperformed all others. This helped spur the developers of Firefox, Safari, Opera and Internet Explorer to improve JavaScript performance in their browsers and it opened a new front in the browser wars.
Technically speaking, V8 takes a slightly novel approach to improving performance. Certain JavaScript objects are dynamically compiled directly into native machine code before execution based on a predictive analysis of the code.
This, along with a new approach to property access and a more efficient garbage collection system enabled Chrome to initially post significantly faster benchmarks than other browsers.
Save 50% - JavaScript Ebooks and Videos
JavaScript is everywhere: servers, rich web client libraries, HTML5, databases, even JavaScript-based languages. If you've avoided JavaScript, this is the year to learn it. And if you don't, you risk being left behind. Whatever your level, we have you covered:
Introductory / Intermediate / Advanced
One week only—offer expires 14 June. Use discount code HALFD in the shopping cart. Buy now and SAVE.
The other browsers responded with improved or completely rewritten JavaScript engines that matched or exceeded V8's benchmarks. These optimizations are still going on, and Google's V8 is benefiting from the healthy, often technically brilliant, competition. Compared to the interpreters for server-side dynamic languages like Ruby, Python, PHP and Perl, JavaScript now has several efficient and incredibly fast runtimes.
Ryan Dahl, creator of Node.js, chose the V8 engine for Node. This has an additional benefit for a server-side implementation.
The predictive optimization of JavaScript works fairly well in the Chrome browser, but it is much more effective for server applications where the same chunks of code tend to be run multiple times. V8 is able to refine its optimizations and soon ends up with very efficient cached machine code.
Node has an additional performance advantage (a big one) that is not directly tied to V8, but we'll get to that in a bit.
The rehabilitation of JavaScript
JavaScript was once widely regarded as an awful hack of a language. Many programmers still feel this way, but the prejudice is starting to fade, mostly because there is a growing body of good code that shows off the language.
One person who has done much to pinpoint JavaScript's technical weak points is Douglas Crockford. Fortunately, instead of stopping there, he has also created JSLint and written "JavaScript: The Good Parts" to help developers write better code while avoiding most of the "bad parts" of the language. In his presentations and posts, one of his core assertions is that:
... despite JavaScript's astonishing shortcomings, deep down, in its
core, it got something very right. When you peel away the cruft, there
is an expressive and powerful programming language there. That
language is being used well in many Ajax libraries to manage and
augment the DOM, producing an application platform for interactive
applications delivered as web pages. Ajax has become popular because
JavaScript works. It works surprisingly well.
Without getting into the details of which parts are good or bad, we have seen in the past few years that professional developers have come to realize that JavaScript is not going away. Many of developers have gotten on with the task of building complex, well-designed applications and libraries. There are still problems with JavaScript and with its specification, but programmers are now much less likely to dismiss it out of hand.
Previous server-side JavaScript frameworks had a much harder time overcoming the negative mindset about the language. By the time Node arrived, JavaScript had overcome the most of its image problem.
Node.js solves a real problem
Wikipedia has a fairly comprehensive "Comparison of server-side JavaScript solutions". Node is in there, but most of the others listed are not nearly so well known. The use of the term "solutions" is interesting, as most of these projects are solutions to problems that have already been solved by other languages.
Python, Java, Ruby, PHP, Perl and others are all still extremely good choices for most types of dynamic web applications. They talk to databases, crunch numbers, validate data, and parse templates. They are high-level languages, and there are several MVC frameworks for each of them for quick web app creation. Node is sometimes touted as the next Ruby-on-Rails, but this a bad comparison and misses the point of what Node is for.
Node is not trying to solve the same problems as Rails, and it's not competing head-on with any of the other languages or frameworks in the areas where they do well. It was made for, and is most successful at, solving a special set of problems with modern web applications. What can it do that these other languages cannot?
It turns out that what JavaScript can do is the flip side of something it can't do: blocking I/O.
Evented I/O
JavaScript itself can't actually read or write to the filesystem. This ability was omitted from the language because it wasn't necessary for its job in the browser, so Node was able to start from scratch with an I/O system based on event loops.
Node is all about "evented I/O," but what does that actually mean?
To those of us who are either not programmers or are not familiar with event loops, an analogy might help.
You're in a grocery store with a list of items to buy. You wheel your cart around the store, pick up one item at a time, put it in your cart, then take the cart through the checkout. You can optimize this slightly by fetching the items in a sane order, but you can't go get the milk while you're waiting at the deli counter.
If you're in a hurry, you might start thinking of crazy ways to speed up the process. You could enlist a number of other shoppers with shopping carts and send each out to buy a single item. This would create bottlenecks in narrow isles and a huge traffic jam at the checkout
This is clearly an insane way to solve the issue because it throws more shopping carts and cash registers at the problem than needed.
Programming languages that block on I/O often try to solve similar problems by spawning additional threads or processes (c.f. Apache, sendmail). This can be expensive in terms of memory usage, and an analysis of Python's Global Interpreter Lock shows just how expensive the traffic jam can be in terms of CPU utilization.
JavaScript and Node use event loops and callbacks to approach the problem differently.
Returning to the shopping example: If you had a group of kids along with you on your shopping trip, you could send each off to get a single item and return them to the cart. When they've all returned, you can proceed through the checkout. The time taken in fetching items would be the maximum time for retrieving a single item (the kid who had to wait at the deli counter), rather than the sum (picking up the items in sequence). Using runners for the small, simple task of fetching items is a more efficient way of parallelizing the problem than sending out full-fledged shoppers and carts.
It's not a perfect analogy by any means, but more succinct and accurate descriptions involve code or pseudo-code. Ryan Dahl's initial presentation at JSConf 2009 used the following example:
var result = db.query("select..");
// use result
Here the database query blocks the program from doing anything else until the query is returned, whereas in an event loop:
db.query("select..", function (result) {
// use result
});
... the program can continue doing things while waiting for the function to call provide its callback.
Node provides non-blocking libraries for database, file and network access. Since I/O is not a fundamental part of JavaScript, nothing had to be taken away to add them. Python's Twisted and Ruby's Event Machine have to work around some basic language components in order to get similar evented behavior.
So, in addition to the performance wins Node gets "for free" by using the V8 JavaScript engine, the event loop model itself allows Node servers to handle massive concurrencies in network connections very efficiently. It often approaches the benchmarks achieved by high-performance reverse proxies like Nginx (which is also based on an event loop).
Sh[…]
june 2011 by cloudseer
Server 1.36.2 Deploy (emergency)
february 2010 by cloudseer
Due to a severe content theft bug, we are executing an emergency deploy of Server 1.36.2.20208 today. This will be a full-grid roll starting ASAP.
2010-02-18, ~9:00a: Full sim rollApologies for any inconveniences the restart may cause you, but please understand that this action is being taken to protect against in world content theft.
As with all of our server deploys, each region will be restarted once during one of the rolling restart periods. Most regions should be down no more than 5-10 minutes, although some fraction of the regions will take 20-30 minutes to upgrade. If your region stays down for more than 30 minutes, please contact support. Each region will receive warnings starting 5 minutes before that region is restarted.
For questions, updates, and discussion, visit the corresponding discussion page.
agni
rolling_restart
server
shared
from google
2010-02-18, ~9:00a: Full sim rollApologies for any inconveniences the restart may cause you, but please understand that this action is being taken to protect against in world content theft.
As with all of our server deploys, each region will be restarted once during one of the rolling restart periods. Most regions should be down no more than 5-10 minutes, although some fraction of the regions will take 20-30 minutes to upgrade. If your region stays down for more than 30 minutes, please contact support. Each region will receive warnings starting 5 minutes before that region is restarted.
For questions, updates, and discussion, visit the corresponding discussion page.
february 2010 by cloudseer
Asset scanning with nmap and ndiff
october 2009 by cloudseer
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)
Linux
Networks
Open_Source
Security
Server
Tutorials_Basic
asset_management
ndiff
network_scans
nmap
port_scanning
shared
from google
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)
october 2009 by cloudseer
Create your own Certificate Authority with TinyCA
september 2009 by cloudseer
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.
Advice
Linux
Open_Source
Security
Server
Tutorials_Basic
software
CAs
certificate_authority
server_security
SubCAs
web_server_security
shared
from google
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.
september 2009 by cloudseer
related tags
Advice ⊕ agni ⊕ asset_management ⊕ CAs ⊕ certificate_authority ⊕ javascript ⊕ Linux ⊕ ndiff ⊕ Networks ⊕ network_scans ⊕ nmap ⊕ nodejs ⊕ Open_Source ⊕ port_scanning ⊕ Programming ⊕ rolling_restart ⊕ Security ⊕ server ⊖ server_security ⊕ shared ⊖ software ⊕ SubCAs ⊕ Tutorials_Basic ⊕ web_server_security ⊕Copy this bookmark: