Error Detection and Correction Suite for Freeipa Infrastructure

Total Page:16

File Type:pdf, Size:1020Kb

Error Detection and Correction Suite for Freeipa Infrastructure MASARYK UNIVERSITY FACULTY OF INFORMATICS Û¡¢£¤¥¦§¨ª«¬­Æ°±²³´µ·¸¹º»¼½¾¿Ý Error detection and correction suite for FreeIPA infrastructure BACHELOR THESIS Tomáš Babej Brno, spring 2015 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Tomáš Babej Advisor: Ing. Mgr. et Mgr. Zdenˇek Ríha,ˇ Ph.D. i Acknowledgment I would like to express my gratitude towards everybody who supported my during writing of the thesis. I want to thank Ing. Mgr. et Mgr. Zdenˇek Ríha,ˇ Ph.D. for his help and patient, prompt responses during supervision of my thesis. Additionally, I’m grateful for the support and technological help received from the FreeIPA developers, namely Ing. Petr Špaˇcek,Ing. Martin Košek and MSc. Alexander Bokovoy. ii Abstract The aim of this thesis is to implement a pluggable troubleshooting tool that collects and analyzes information about FreeIPA deployment. The thesis provides a detailed view on the architecture of FreeIPA servers and clients, their interaction and the technologies they are based on. Afterwards, high- level design and implementation details are featured, which serves as a guide for further extension by FreeIPA developers. iii Keywords FreeIPA, LDAP, Kerberos, PKI, Cockpit, troubleshooting, pluggable, tool iv Contents 1 Goal of the Thesis ...........................1 2 Foundational technologies ......................3 2.1 Lightweight Directory Access Protocol . .3 2.1.1 Directory services . .3 2.1.2 Structure of a LDAP directory . .4 2.1.3 LDAP protocol . .6 2.1.4 Replication . .6 2.2 Kerberos . .7 2.2.1 Basic properties . .7 2.2.2 Kerberos terminology . .8 2.2.3 Protocol . .9 2.2.3.1 The Needham–Schroeder Protocol . .9 2.2.3.2 Kerberos v4 . 10 2.2.3.3 Kerberos v5 . 12 2.3 PKI infrastructure . 12 2.3.1 Digital certificate . 13 2.3.2 Certificate authority . 14 3 FreeIPA .................................. 15 3.1 High level functionality . 15 3.2 Server Architecture . 16 3.2.1 Backend . 16 3.2.2 Authentication component . 17 3.2.3 Certificate authority . 18 3.2.4 DNS server . 19 3.2.5 NTP server . 20 3.2.6 Samba server . 20 3.2.7 Management framework . 20 3.3 Client architecture . 22 3.3.1 SSSD . 22 3.3.2 Certmonger . 23 3.4 Common issues . 23 4 Implementation ............................. 25 4.1 Goals . 25 4.2 Overview . 25 4.2.1 Local data collection . 26 4.2.2 Remote data collection . 26 4.2.3 Presentation layer . 27 v 4.3 Details . 28 4.3.1 Core . 28 4.3.2 Plugin class hierarchy . 29 4.3.3 Reporter plugins . 29 4.3.4 Doctor plugins . 31 4.4 Cockpit integration . 32 4.5 Next development . 33 5 Conclusion ................................ 35 vi 1 Goal of the Thesis Nearly every organization, independent on its size, needs at one point to authenticate and authorize its members. While mechanisms for authentica- tion and authorization have historically been document or human based, with the large number of information systems in use, the burden of this problem is being shifted to computers. As most complex software solutions available today, the authentication and authorization systems have evolved from simple ideas. The authenti- cation and authorization in Unix based systems was localized and insecure at first, as can be seen from the fact that even passwords used to be stored in system configuration files in a plain text form. [18] Since then this area, which is also referred to as Identity Management, has grown in complexity. The need to solve these problems encouraged the development and several related technologies were developed. Centralization of the identity infor- mation became easier with directory services, such as Lightweight Direc- tory Access Protocol (LDAP) servers. Public key encryption in the form of digital certificates became more widespread and new network authentica- tion and authorization protocols, such as Kerberos, were developed. This improvement in security came with a cost of increased burden on system administrators, who now have to setup and manage systems much more complex than those in the past. Deployment of the these systems re- quires domain-specific knowledge in multiple areas, and therefore is prone to misconfiguration and security errors. FreeIPA is a community software project that aims to solve the still- growing need of centralized solution for authentication and authorization in the Linux environments. It integrates several already time-proven tech- nologies (such as aforementioned LDAP, Kerberos, DNS or CA) in one com- prehensive software bundle with automated installation and common man- agement framework. However, given the sheer complexity of the system, various system mis- configurations can still throw user off the track. Since FreeIPA project pro- vides most value for less knowledgeable system administrators, the hunt for the solution often becomes painful, given their lack of expertise. To improve the usability of the project, this thesis aims to create a pluggable tool for collecting information about the FreeIPA deployment, and analyz- ing this information so that common misconfiguration and pitfalls can be avoided automatically. In the second chapter, we shall elaborate on technologies that collec- 1 1. GOAL OF THE THESIS tively create the foundation of the FreeIPA server, thus giving the reader a necessary insight that will be required to understand the next chapters and the inherent problems of the FreeIPA misconfiguration. The third chapter will focus on the architecture of the FreeIPA server and clients and their capabilities, thus enhancing the relevant domain specific knowledge. Con- sequently, we explore the most frequent and important misconfiguration problems and the implementation of the diagnosis tool itself. 2 2 Foundational technologies This chapter aims to enlighten the reader with the entry level knowledge necessary to understand the technologies that FreeIPA project bundles and their interaction. Due to the complexity of the topic presented, basic con- cepts, such as principles of symmetric encryption will be assumed as known to the reader. If necessary, pointers to the sources with additional explana- tion will be provided. Topic that will be presented have been carefully selected based on their impact on the inner workings of the FreeIPA server. • Lightweight Directory Access Protocol, LDAP,as the backend database FreeIPA uses to store most of the information • Kerberos, as the main network authentication protocol used in FreeIPA • Public Key Infrastructure (PKI) 2.1 Lightweight Directory Access Protocol Lightweight Directory Access Protocol is a network application protocol that provides access to directory information services, which will be de- fined in the next subsection. It was developed as a conjoined effort of Uni- versity of Michigan and private sector companies to provide a lightweight alternative to its predecessor, X.500 Directory Access Protocol (DAP), which required the usage of OSI protocol stack. LDAP protocol originally sup- ported a subset of the DAP’s functionality, which was defined by a series of computer networking standards called X.500, hence it was also referred to as X.500-lite. The most current version of the protocol is LDAPv3, devel- oped by the Internet Engineering Task Force, and therefore it has been pub- lished in its standard track publication Requests for Comments (RFC). Its current specification is RFC 4511, however, many extensions to the LDAPv3 have been published, such as RFC 4530 or RFC 5020. 2.1.1 Directory services A directory service is a software system that serves to store and organize data. Unlike traditional relational databases, directory services store data of more descriptive nature, which are attribute based, concise and only rel- evant to the particular entry where they are stored. Read operations in di- rectories are optimized at cost of write operations, since majority of the re- 3 2. FOUNDATIONAL TECHNOLOGIES quests are usually value lookups or search operations. For this reason, data is often made redundant within the directory, if it helps performance. [1] Directory services can be very flexible, ranging from specialized direc- tories, that allow only certain data and node types, to very generic ones, that allow a broad range of potentionally extensible data types. A real life example of the former type of the directory service is a telephone directory, where the only node type is a name and data type are the telephone num- bers. An example of the latter would be a Domain Name Service, as the nodes within DNS can store values containing not only IP addresses, but also domain aliases, key fingerprints or certificates. 2.1.2 Structure of a LDAP directory Directory information services, such as LDAP server, follow the X.500 model. Entries are stored in a hierarchically structured trees, each within the LDAP’s directory namespace, which is often referred to as suffix. Suffix usually cor- responds to the DNS domain name. This allows to properly map the LDAP directories to their corresponding DNS zones in the hierarchy. Figure 2.1: Example of a LDAP directory structure 4 2. FOUNDATIONAL TECHNOLOGIES Each entry in the directory can contain only an allowed set of attributes, which are specified by the entry’s objectclasses. The objectclasses for the given entry are specified in a special attribute called objectclass. Each objectclass has a number of properties, such as its object iden- tifier (OID), type, superclasses, mandatory attributes it enforces and op- tional attributes it allows. Objectclasses themselves are defined in the server schema. Server schema specifies the inner structure of the entries in the directory: it lists all the possible objectclasses, their types and mutual rela- tionships. It also defines the attributes themselves, their allowed syntax and matching rules.
Recommended publications
  • Open Directory & Openldap
    Open Directory & OpenLDAP David M. O’Rourke Engineering Manager Overview • Background on Apple’s Open Directory Technology (8 minutes) – What is it – What is Directory Services • How has Apple integrated OpenLDAP (20 minutes or less) – what has Apple added to OpenLDAP? • Questions and Answers (remaining time) Open Directory • Open Directory is a technology name – Covers both client access technologies and server technologies – Integrates and promotes industry standard technologies • Open Directory is built into Mac OS X & Mac OS X Server – Been there since 10.0 • Open Sourced as part of Darwin – http://developer.apple.com/darwin/projects/ opendirectory/ What Is Directory Services • Abstraction API for read/write access to system configuration and management data – Users, groups, mount records and others – Authentication abstraction Mac OS X Software Directory Services NetInfo LDAP BSD Files Other… Directory Services in 10.3 • Includes – LDAPv3 (read/write), Native Active Directory, NetInfo, NIS, BSD/etc files – Service Discovery: Rendezvous, SMB, AppleTalk, and SLP – LDAPv3 client support replication fail over • Documented Access API and plug-in API – SDK posted – Sample code, sample plug-in, notes – Directory Services Headers are installed in – /System/Library/Frameworks/DirectoryService.framework – Command line tool for directory editing ‘dscl’ 10.3 Usage of Directory Services • Login Window uses Directory Services for all user authentication – Managed Desktop • All Security Framework authentication uses Directory Services • Legacy Unix
    [Show full text]
  • AWS Directory Service Setup with Netapp Cloud Volumes Service for AWS Prabu Arjunan, Netapp August 2019
    AWS Directory service setup with NetApp Cloud Volumes Service for AWS Prabu Arjunan, NetApp August 2019 Abstract This document provides instructions to help users set up the AWS directory services environment for using NetApp® Cloud Volumes Service for Amazon Web Services (AWS). TABLE OF CONTENTS 1 Overview ................................................................................................................................................ 3 2 Requirements ........................................................................................................................................ 3 3 Creating the AWS Active Directory service ....................................................................................... 4 4 Adding the Active Directory server to Cloud Volumes Service ..................................................... 10 5 Creating a cloud volume that uses the Active Directory server .................................................... 12 Common errors messages....................................................................................................................... 14 References ................................................................................................................................................. 14 Version History ......................................................................................................................................... 14 2 AWS Directory service setup with NetApp Cloud Volume Service for AWS © 2019 NetApp, Inc. All rights reserved. 1 Overview
    [Show full text]
  • White Paper | September 2 0 1 7
    Oracle Directory Services Buyer’s Guide ORACLE WHITE PAPER | SEPTEMBER 2 0 1 7 Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. ORACLE DIRECTORY SERVICES – BUYER’S GUIDE Table of Contents Introduction 1 Business Drivers 2 Oracle Directory Services 3 Key Considerations for Some Popular Scenarios 4 Cloud 4 Mobile 4 Customer-Facing Internet 4 Employee-Facing Intranet 5 Directory Services Checklist 5 Conclusion 7 ORACLE DIRECTORY SERVICES – BUYER’S GUIDE Introduction In the late 1990s, directory servers were essentially designed as white-page applications for providing users with secure access to enterprise resources through authentication and authorization processes. Since then, their use has been extended to partners and customers, thus creating the need to support an increasing number of diverse users and communities. Today, directory services need to accommodate hundreds of millions of users and provide additional services to break identity silos. With the ubiquitous use of mobile devices as well as cloud deployments and the integration of social networks identities into the enterprise fabric, billions of objects are transacted everyday through directory services. Modern directory services now go beyond the initial capability to store objects in an identity repository. Directory solutions have evolved around three foundation services: » Storage: Persisting and maintaining entries representing identities.
    [Show full text]
  • Questions for Openshift
    www.YoYoBrain.com - Accelerators for Memory and Learning Questions for OpenShift Category: Default - (402 questions) OpenShift:  2 primary tools to serve 1. container runtime - creates containers in application in OpenShift platform Linux 2. orchestration engine - manage cluster of servers running containers OpenShift:  routing layer a software load balancer, when an application is deployed in OpenShift, a DNS entry is created and added to the load balancer, which interfaces with the Kubernetes service OpenShift:  log into cluster and create oc login -u dev -p dev http://....:8443 user named dev with password dev OpenShift:  what is the default port for 8443 OpenShift cluster OpenShift:  what is a cluster's initial All All identity provider user name/password configuration allows any user and password combination to log in. OpenShift:  ____ are the fundamental projects way applications are organized OpenShift:  to create a project called oc new-project image-update image-update --display-name='My image update project' OpenShift:  how to change to project oc project myProj myProj OpenShift:  each application application source code deployment's image is created using _____ custom base image called a builder image and ____ OpenShift:  the component that build config controls the creation of your application containers is _____ OpenShift:  ____ contains all the info build config needed to build an application using its source code OpenShift:  4 things in build config 1. URL for the application source code 2. Name of builder image to use 3. Name of the application container image that is created 4.
    [Show full text]
  • The 12 Essential Tasks of Active Directory Domain Services
    WHITE PAPER ACTIVE DIRECTORY DOMAIN SERVICES The 12 Essential Tasks of Active Directory Domain Services Using the right tools and processes helps reduce administrative overhead and ensures directory service is always available By Nelson Ruest and Danielle Ruest Sponsored by WHITE PAPER ACTIVE DIRECTORY DOMAIN SERVICES ABSTRACT Active Directory Domain Services (AD DS) administration and management includes Sponsored by 12 major tasks. These tasks cover a wide breadth of business needs and are not all performed solely by AD DS administrators. In fact, administrators can and should delegate several tasks to other members of their technical community, technicians, help desk personnel, even users such as team managers and administrative assistants. While delegation is a way to reduce the amount of work administrators have to do when managing AD DS infrastructures, it really only addresses one or two of the 12 tasks, for example, user and group administration as well as end point device administration. The other ten tasks can be staggering in nature—security, networked service administration, OU-Specific Management, Group Policy Object management and many more—and because of this can take up inordinate amounts of time. You can rely on Microsoft’s built-in tools to reduce some of this workload, but are the native tools enough? Perhaps it’s time to reduce AD DS administration overhead by automating most tasks and tightening internal security. Address this by first, determining what the twelve essential labors of Active Directory are and then, see how you can reduce AD DS workloads through the implementation of proper management and administration tools.
    [Show full text]
  • Vulnerability Summary for the Week of June 5, 2017
    Vulnerability Summary for the Week of June 5, 2017 Please Note: • The vulnerabilities are categorized by their level of severity which is either High, Medium or Low. • The CVE identity number is the publicly known ID given to that particular vulnerability. Therefore, you can search the status of that particular vulnerability using that ID. • The CVSS (Common Vulnerability Scoring System) score is a standard scoring system used to determine the severity of the vulnerability. High Vulnerabilities Primary CVSS Source & Patch Vendor -- Product Description Published Score Info In Apache Hadoop 2.8.0, 3.0.0-alpha1, and 3.0.0-alpha2, the LinuxContainerExecutor runs docker commands as root with CVE-2017-7669 insufficient input validation. When the docker BID(link is feature is enabled, authenticated users can run 2017-06- external) apache -- hadoop commands as root. 04 8.5 MLIST CVE-2017-9364 Unrestricted File Upload exists in BigTree CONFIRM(link CMS through 4.2.18: if an attacker uploads an is external) bigtreecms -- 'xxx.pht' or 'xxx.phtml' file, they could bypass 2017-06- CONFIRM(link bigtree_cms a safety check and execute any code. 02 7.5 is external) CVE-2017-9435 Dolibarr ERP/CRM before 5.0.3 is vulnerable CONFIRM(link to a SQL injection in user/index.php is external) (search_supervisor and search_statut 2017-06- CONFIRM(link dolibarr -- dolibarr parameters). 05 7.5 is external) CVE-2014-9923 In NAS in all Android releases from CAF BID(link is using the Linux kernel, a Buffer Copy external) without Checking Size of Input vulnerability 2017-06- CONFIRM(link google -- android could potentially exist.
    [Show full text]
  • [MS-DSSP]: Directory Services Setup Remote Protocol
    [MS-DSSP]: Directory Services Setup Remote Protocol Intellectual Property Rights Notice for Open Specifications Documentation . Technical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions. Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation. No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting [email protected].
    [Show full text]
  • Pingdirectory Administration Guide Version
    Release 7.3.0.3 Server Administration Guide PingDirectory | Contents | ii Contents PingDirectory™ Product Documentation................................................ 20 Overview of the Server............................................................................. 20 Server Features.................................................................................................................................20 Administration Framework.................................................................................................................21 Server Tools Location....................................................................................................................... 22 Preparing Your Environment....................................................................22 Before You Begin.............................................................................................................................. 22 System requirements..............................................................................................................22 Installing Java......................................................................................................................... 23 Preparing the Operating System (Linux).......................................................................................... 24 Configuring the File Descriptor Limits.................................................................................... 24 File System Tuning.................................................................................................................25
    [Show full text]
  • Oracle Internet Directory 11G R1
    2 3 Directory services are key building blocks for secure identity-enabled business applications and the underlying enterprise identity management (IdM) architecture. Well-structured and organized directory services are the foundation of efficient and effective security services. This is because all IDM applications and most commercial off the shelf (COTS) business applications that require a standard mechanism to access identity attributes, and the most common way to access identity attributes is using LDAP. Example identity attributes include user credentials, access privileges and profile information. Additionally the modern enterprise has different identity attribute needs than they did when LDAP servers first appeared on the market in the 1990s. This is because modern enterprises often have multiple LDAP storage-based servers as well as identity stored in non-LDAP repositories such as HR or CRM databases. Furthermore, new computing initiatives, such as mobile computing, cloud computing and social networking, require LDAP to manage extremely large number of objects, to deliver high performance to manage dynamic data like location and presence, and to be elastic to grow with the cloud. These requirements led to several challenges in deploying identity related applications within the enterprise: While Microsoft Active Directory is pervasive within enterprises, it does not provide the functionality to be a general purpose Enterprise Directory Service because of limitations imposed on it being the Network Operating System directory for Windows. To address Active Directory limitations, Microsoft provides Active Directory Lightweight Directory Services (AD LDS)1. However, due to AD LDS‟s application specific nature, the 1 AD LDS formerly known as Active Directory Application Mode (ADAM) 4 proliferation of AD LDS within enterprises is like weeds in a garden resulting in cost and manageability issues.
    [Show full text]
  • Open Directory Administration for Version 10.5 Leopard Second Edition
    Mac OS X Server Open Directory Administration For Version 10.5 Leopard Second Edition Apple Inc. © 2008 Apple Inc. All rights reserved. The owner or authorized user of a valid copy of Mac OS X Server software may reproduce this publication for the purpose of learning to use such software. No part of this publication may be reproduced or transmitted for commercial purposes, such as selling copies of this publication or for providing paid-for support services. Every effort has been made to make sure that the information in this manual is correct. Apple Inc., is not responsible for printing or clerical errors. Apple 1 Infinite Loop Cupertino CA 95014-2084 www.apple.com The Apple logo is a trademark of Apple Inc., registered in the U.S. and other countries. Use of the “keyboard” Apple logo (Option-Shift-K) for commercial purposes without the prior written consent of Apple may constitute trademark infringement and unfair competition in violation of federal and state laws. Apple, the Apple logo, iCal, iChat, Leopard, Mac, Macintosh, QuickTime, Xgrid, and Xserve are trademarks of Apple Inc., registered in the U.S. and other countries. Finder is a trademark of Apple Inc. Adobe and PostScript are trademarks of Adobe Systems Incorporated. UNIX is a registered trademark of The Open Group. Other company and product names mentioned herein are trademarks of their respective companies. Mention of third-party products is for informational purposes only and constitutes neither an endorsement nor a recommendation. Apple assumes no responsibility with regard to the performance or use of these products.
    [Show full text]
  • Guide to Open Source Solutions
    White paper ___________________________ Guide to open source solutions “Guide to open source by Smile ” Page 2 PREAMBLE SMILE Smile is a company of engineers specialising in the implementing of open source solutions OM and the integrating of systems relying on open source. Smile is member of APRIL, the C . association for the promotion and defence of free software, Alliance Libre, PLOSS, and PLOSS RA, which are regional cluster associations of free software companies. OSS Smile has 600 throughout the World which makes it the largest company in Europe - specialising in open source. Since approximately 2000, Smile has been actively supervising developments in technology which enables it to discover the most promising open source products, to qualify and assess them so as to offer its clients the most accomplished, robust and sustainable products. SMILE . This approach has led to a range of white papers covering various fields of application: Content management (2004), portals (2005), business intelligence (2006), PHP frameworks (2007), virtualisation (2007), and electronic document management (2008), as well as PGIs/ERPs (2008). Among the works published in 2009, we would also cite “open source VPN’s”, “Firewall open source flow control”, and “Middleware”, within the framework of the WWW “System and Infrastructure” collection. Each of these works presents a selection of best open source solutions for the domain in question, their respective qualities as well as operational feedback. As open source solutions continue to acquire new domains, Smile will be there to help its clients benefit from these in a risk-free way. Smile is present in the European IT landscape as the integration architect of choice to support the largest companies in the adoption of the best open source solutions.
    [Show full text]
  • Red Hat Directory Server 11 Installation Guide
    Red Hat Directory Server 11 Installation Guide Instructions for installing Red Hat Directory Server Last Updated: 2021-04-23 Red Hat Directory Server 11 Installation Guide Instructions for installing Red Hat Directory Server Marc Muehlfeld Red Hat Customer Content Services [email protected] Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
    [Show full text]