JS library

From wiki:

A JavaScript library is a library of pre-written JavaScript which allows for easier development of JavaScript-based applications, especially for AJAX and other web-centric technologies.

History

Main article: JavaScript: History

While JavaScript, as first developed by Netscape (and later Mozilla), has long had a presence on the Web for many websites, it gained a particular pitch with the rise of the Web 2.0 era of computing, in which JavaScript became increasingly used for the development of user interfaces for applications, both web-based and desktop-based.

JavaScript was also combined with CSS to create dynamic web pages, which have also become popular as a more efficient and accessible alternative to Flash-based websites.

Libraries

With the expanded demands for JavaScript, an easier means for programmers to develop such dynamic interfaces was needed. Thus, 

- JavaScript libraries such as Prototype, script.aculo.us, Ext Core, jsPHP, MooTools and jQuery 

and 

- JavaScript widget libraries such as Ext JS, DHTMLX, and Dojo Toolkit were developed, 

allowing for developers to concentrate more upon more distinctive applications of Ajax. This has led to other companies and groups, such as Microsoft and Yahoo! developing their own JavaScript-based user interface libraries, which find their way into the web applications developed by these companies.

Some JavaScript libraries allow for easier integration of JavaScript with other web development technologies, such as CSS, PHP, Ruby, and Java. Many libraries include code to detect differences between runtime environments, and remove the need for applications to allow for such inconsistencies.

Almost all JavaScript libraries are released under either a copycenter or copyleft license to ensure license-free distribution, usage, and modification.

Frameworks[edit]

Some JavaScript libraries, such as YUI, are classified as frameworks since they exhibit full-stack capabilities and properties not found in general JavaScript libraries.

Web based SSH - ajaxterm setup on ubuntu 13.10

from Wiki: http://en.wikipedia.org/wiki/Web-based_SSH

Web-based SSH clients basically consist of the following parts:

• Client-side: Typically JavaScript and dynamic HTML pages are used to capture keystrokes, transmit messages to/from the server and display the results in the user's web browser.
• Server-side/Web application: Incoming requests are processed on the web application server. Keyboard events are forwarded to a secure shell client communicating with the connected SSH server. Terminal output is either passed to the client where it is converted into HTML via JavaScript or it is translated into HTML by the server before it is transmitted to the client.

Client-side terminal emulation

Web-based SSH servers that utilize client-side terminal emulation typically transmit the raw terminal output from the SSH server directly to the client. This has the advantage of offloading the process of translating terminal output into HTML on to the client. The disadvantage of this method is that it is limited by the capabilities of JavaScript and it will use up a non-trivial amount of the client's CPU and memory to process the incoming character stream. It also relies on the client to keep track of the terminal state and respond to escape sequences.

Client-side terminal emulator example: vt100.js (from Shell in a Box)

Server-side terminal emulation

Web-based SSH servers that utilize server-side terminal emulation typically keep track of the terminal screen and state in memory and convert it to HTML either when a screen update occurs or when the client expressly requests an update. The advantage of this method is that the state of the terminal remains persistent even if the user connects to their existing session(s) from a different web browser. It also enables the server to act upon terminal output even if the user is disconnected.^[1] The disadvantage of this method is that it uses up more CPU and memory on the server.

Server-side terminal emulator example: terminal.py (From Gate One).

Advantages

The main advantages of web-based SSH can be summarized as follows:

• Accessibility: Web-based SSH as described in this article requires no local installation of client software. It is thus possible to access SSH servers through a web browser from anywhere. As communication is based on HTTP or HTTPS it is also possible to access SSH servers from behind a firewall or proxy that restricts Internet access to only ports 80 (HTTP) or 443 (HTTPS).
• Anonymous Access: As SSH access is tunneled through an intermediary web application server it is this server which actually communicates with the SSH server. This means that the SSH server will only be aware of the IP address of the web application server, keeping the actual client's IP address hidden.
• Auditability: Because all communication between the client and the SSH server must pass through the web application serverthis communication can be logged. This prevents a malicious client from deleting logs of their activities.
• Resuming Sessions: Some web-based SSH implementations allow the user to resume their SSH sessions after being disconnected. This is not possible with a traditional SSH client.
• Embeddable: Web-based SSH implementations can be embedded into any web page allowing them to be integrated into other web-based applications.
• Unique Features: Many web-based SSH tools have unique features such as the ability to share terminals with other users, can display images within terminals, and other useful capabilities.

--- ajaxterm on Ubuntu setup

https://help.ubuntu.com/community/AjaxTerm

https://help.ubuntu.com/12.10/serverguide/certificates-and-security.html

https://help.ubuntu.com/12.10/serverguide/httpd.html#https-configuration

1, sudo apt-get install ajaxterm

You will need to enable SSH password authentication for AjaxTerm to work.

2, uncomment "PasswordAuthentication yes" in /etc/ssh/sshd_config.conf

3, sudo service ssh restart

4, configure Apache2 for HTTPS and generate a certificate

------------------------------------------------------------------------------------------------------------------------

Generating a Certificate Signing Request (CSR)

Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key.

If the certificate will be used by service daemons, such as Apache, Postfix, Dovecot, etc, a key without a passphrase is often appropriate. Not having a passphrase allows the services to start without manual intervention, usually the preferred way to start a daemon.

This section will cover generating a key with a passphrase, and one without. The non-passphrase key will then be used to generate a certificate that can be used with various service daemons.

Running your secure service without a passphrase is convenient because you will not need to enter the passphrase every time you start your secure service. But it is insecure and a compromise of the key means a compromise of the server as well.

To generate the keys for the Certificate Signing Request (CSR) run the following command from a terminal prompt:

openssl genrsa -des3 -out server.key 2048

Generating RSA private key, 2048 bit long modulus
..........................++++++
.......++++++
e is 65537 (0x10001)
Enter pass phrase for server.key:

You can now enter your passphrase. For best security, it should at least contain eight characters. The minimum length when specifying -des3 is four characters. It should include numbers and/or punctuation and not be a word in a dictionary. Also remember that your passphrase is case-sensitive.

Re-type the passphrase to verify. Once you have re-typed it correctly, the server key is generated and stored in the server.key file.

Now create the insecure key, the one without a passphrase, and shuffle the key names:

openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key

The insecure key is now named server.key, and you can use this file to generate the CSR without passphrase.

To create the CSR, run the following command at a terminal prompt:

openssl req -new -key server.key -out server.csr

It will prompt you enter the passphrase. If you enter the correct passphrase, it will prompt you to enter Company Name, Site Name, Email Id, etc. Once you enter all these details, your CSR will be created and it will be stored in the server.csr file.

You can now submit this CSR file to a CA for processing. The CA will use this CSR file and issue the certificate. On the other hand, you can create self-signed certificate using this CSR.

Creating a Self-Signed Certificate

To create the self-signed certificate, run the following command at a terminal prompt:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

The above command will prompt you to enter the passphrase. Once you enter the correct passphrase, your certificate will be created and it will be stored in the server.crt file.

If your secure server is to be used in a production environment, you probably need a CA-signed certificate. It is not recommended to use self-signed certificate.

Installing the Certificate

You can install the key file server.key and certificate file server.crt, or the certificate file issued by your CA, by running following commands at a terminal prompt:

sudo cp server.crt /etc/ssl/certs
sudo cp server.key /etc/ssl/private

Now simply configure any applications, with the ability to use public-key cryptography, to use the certificate and key files. For example, Apache can provide HTTPS, Dovecot can provide IMAPS and POP3S, etc.

HTTPS Configuration

The mod_ssl module adds an important feature to the Apache2 server - the ability to encrypt communications. Thus, when your browser is communicating using SSL, the https:// prefix is used at the beginning of the Uniform Resource Locator (URL) in the browser navigation bar.

The mod_ssl module is available in apache2-common package. Execute the following command from a terminal prompt to enable the mod_sslmodule:

sudo a2enmod ssl

There is a default HTTPS configuration file in /etc/apache2/sites-available/default-ssl. In order for Apache2 to provide HTTPS, acertificate and key file are also needed. The default HTTPS configuration will use a certificate and key generated by the ssl-cert package. They are good for testing, but the auto-generated certificate and key should be replaced by a certificate specific to the site or server. For information on generating a key and obtaining a certificate see Certificates

To configure Apache2 for HTTPS, enter the following:

sudo a2ensite default-ssl

The directories /etc/ssl/certs and /etc/ssl/private are the default locations. If you install the certificate and key in another directory make sure to change SSLCertificateFile and SSLCertificateKeyFile appropriately.

With Apache2 now configured for HTTPS, restart the service to enable the new settings:

sudo service apache2 restart

Depending on how you obtained your certificate you may need to enter a passphrase when Apache2 starts.

You can access the secure server pages by typing https://your_hostname/url/ in your browser address bar.

------------------------------------------------------------------------------------------------------------------------

Now copy [then symlink] the SSL config from the Available sites to the Enabled sites

5, sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/ssl

Make sure all the modules and sites for proxy and ssl have been enabled.

6, sudo a2enmod proxy_http
6, sudo a2enmod ssl
6, sudo a2ensite default-ssl

It is time to decide on an htaccess password and username. Remember to make this password strong.

7, sudo mkdir /srv/ajaxterm
8, sudo htpasswd -bc /srv/ajaxterm/.htpasswd [user] [pass]

You will now need to edit the default Apache SSL configuration.

9, sudo nano -w /etc/apache2/sites-enabled/default-ssl.conf

Insert just before </VirtualHost>:

        ProxyRequests Off
        <Proxy *>
                AuthUserFile /srv/ajaxterm/.htpasswd
                AuthName EnterPassword
                AuthType Basic
                require valid-user

                Order Deny,allow
                Allow from all
        </Proxy>
        ProxyPass / http://localhost:8022/
        ProxyPassReverse / http://localhost:8022/

Restart apache2.

10, sudo service apache2 restart

Open your firewall port 443 and try to browse to https://yourhost.foo where yourhost.foo is either your IP adress or your hostname/web address.

--- ajaxterm on Ubuntu 

https://help.ubuntu.com/community/AjaxTerm

https://help.ubuntu.com/12.10/serverguide/certificates-and-security.html

https://help.ubuntu.com/12.10/serverguide/httpd.html#https-configuration

Routing

- problem definition
In graph theory, the shortest path problem is the problem of finding a path between two vertices (or nodes) in a graph such that the sum of the weights of its constituent edges is minimized.

- algorithm

The most important algorithms for solving this problem are:

• Dijkstra's algorithm solves the single-source shortest path problems.
• Bellman–Ford algorithm solves the single-source problem if edge weights may be negative.
• A* search algorithm solves for single pair shortest path using heuristics to try to speed up the search.
• Floyd–Warshall algorithm solves all pairs shortest paths.
• Johnson's algorithm solves all pairs shortest paths, and may be faster than Floyd–Warshall on sparse graphs.

Additional algorithms and associated evaluations may be found in Cherkassky et al.^[1]

===============================================================================

- routing

Routing schemes differ in their delivery semantics:

• unicast delivers a message to a single specific node
• broadcast delivers a message to all nodes in the network
• multicast delivers a message to a group of nodes that have expressed interest in receiving the message
• anycast delivers a message to anyone out of a group of nodes, typically the one nearest to the source
• geocast delivers a message to a geographic area

Unicast is the dominant form of message delivery on the Internet. This article focuses on unicast routing algorithms.

- algorithm

Distance vector algorithms (Main article: Distance-vector routing protocol)

Distance vector algorithms use the Bellman–Ford algorithm. This approach assigns a cost number to each of the links between each node in the network. Nodes will send information from point A to point B via the path that results in the lowest total cost (i.e. the sum of the costs of the links between the nodes used).

The algorithm operates in a very simple manner. When a node first starts, it only knows of its immediate neighbours, and the direct cost involved in reaching them. (This information — the list of destinations, the total cost to each, and the next hop to send data to get there — makes up the routing table, or distance table.) Each node, on a regular basis, sends to each neighbour node its own current assessment of the total cost to get to all the destinations it knows of. The neighbouring nodes examine this information and compare it to what they already 'know'; anything that represents an improvement on what they already have, they insert in their own routing table(s). Over time, all the nodes in the network will discover the best next hop for all destinations, and the best total cost.

When one network nodes goes down, any nodes that used it as their next hop discard the entry, and create new routing-table information. These nodes convey the updated routing information to all adjacent nodes, which in turn repeat the process. Eventually all the nodes in the network receive the updates, and discover new paths to all the destinations they can still "reach". e.g. RIPV1,RIPV2

 - The Routing Information Protocol (RIP) is one of the oldest distance-vector routing protocol, which employs the hop count as a routing metric. RIP prevents routing loops by implementing a limit on the number of hops allowed in a path from the source to a destination. The maximum number of hops allowed for RIP is 15. This hop limit, however, also limits the size of networks that RIP can support. A hop count of 16 is considered an infinite distance, in other words the route is considered unreachable.

RIP implements the split horizon, route poisoning and holddown mechanisms to prevent incorrect routing information from being propagated. These are some of the stability features of RIP. It is also possible to use the Routing Information Protocol with Metric-Based Topology (RMTI)^[1] algorithm to cope with the count-to-infinity problem. With RMTI, it is possible to detect every possible loop with a very small computation effort.

Originally, each RIP router transmitted full updates every 30 seconds. In the early deployments, routing tables were small enough that the traffic was not significant. As networks grew in size, however, it became evident there could be a massive traffic burst every 30 seconds, even if the routers had been initialized at random times. It was thought, as a result of random initialization, the routing updates would spread out in time, but this was not true in practice. Sally Floyd and Van Jacobson showed in 1994^[2] that, without slight randomization of the update timer, the timers synchronized over time. In most current networking environments, RIP is not the preferred choice for routing as its time to converge and scalability are poor compared to EIGRP, OSPF, or IS-IS (the latter two being link-state routing protocols), and (without RMTI) a hop limit severely limits the size of network it can be used in. However, it is easy to configure, because RIP does not require any parameters on a router unlike other protocols.

RIP uses the User Datagram Protocol (UDP) as its transport protocol, and is assigned the reserved port number 520.^[3]

Link-state algorithms (Main article: Link-state routing protocol)

When applying link-state algorithms, a graphical map of the network is the fundamental data used for each node. To produce its map, each node floods the entire network with information about the other nodes it can connect to. Each node then independently assembles this information into a map. Using this map, each router independently determines the least-cost path from itself to every other node using a standard shortest paths algorithm such as Dijkstra's algorithm. The result is a tree graph rooted at the current node, such that the path through the tree from the root to any other node is the least-cost path to that node. This tree then serves to construct the routing table, which specifies the best next hop to get from the current node to any other node.

- IS-IS (pronounced "i-s i-s") is an interior gateway protocol, designed for use within an administrative domain or network. This is in contrast to Exterior Gateway Protocols, primarily Border Gateway Protocol (BGP), which is used for routing between autonomous systems (RFC 1930). The protocol was defined in ISO/IEC 10589:2002 as an international standard within the Open Systems Interconnection (OSI) reference design. Though originally an ISO standard, the IETF republished the protocol as an Internet Standard in RFC 1142. IS-IS has been called "the de facto standard for large service provider network backbones."^[1]

IS-IS is a link-state routing protocol, operating by reliably flooding link state information throughout a network of routers. Each IS-IS router independently builds a database of the network's topology, aggregating the flooded network information. Like the OSPF protocol, IS-IS uses Dijkstra's algorithm for computing the best path through the network. Packets (datagrams) are then forwarded, based on the computed ideal path, through the network to the destination.

- Open Shortest Path First (OSPF) is a link-state routing protocol for Internet Protocol (IP) networks. It uses a link state routing algorithm and falls into the group of interior routing protocols, operating within a single autonomous system (AS). It is defined as OSPF Version 2 in RFC 2328 (1998) for IPv4.^[1] The updates for IPv6 are specified as OSPF Version 3 in RFC 5340 (2008).^[2]

OSPF is perhaps the most widely used interior gateway protocol (IGP) in large enterprise networks. IS-IS, another link-state dynamic routing protocol, is more common in large service provider networks. The most widely used exterior gateway protocol is the Border Gateway Protocol (BGP), the principal routing protocol between autonomous systems on the Internet.

-----------

Both IS-IS and OSPF are link state protocols, and both use the same Dijkstra algorithm for computing the best path through the network. As a result, they are conceptually similar. Both support variable length subnet masks, can use multicast to discover neighboring routers using hello packets, and can support authentication of routing updates.

While OSPF is natively built to route IP and is itself a Layer 3 protocol that runs on top of IP, IS-IS is natively an OSI network layer protocol (it is at the same layer as CLNS). The widespread adoption of IP worldwide may have contributed to OSPF's popularity. IS-IS does not use IP to carry routing information messages. IS-IS is neutral regarding the type of network addresses for which it can route. OSPF, on the other hand, was designed for IPv4. This allowed IS-IS to be easily used to support IPv6. To operate with IPv6 networks, the OSPF protocol was rewritten in OSPF v3 (as specificed in RFC 2740).

IS-IS routers build a topological representation of the network. This map indicates the subnets which each IS-IS router can reach, and the lowest-cost (shortest) path to a subnet is used to forward traffic.

IS-IS differs from OSPF in the way that "areas" are defined and routed between. IS-IS routers are designated as being: Level 1 (intra-area); Level 2 (inter area); or Level 1-2 (both). Level 2 routers are inter area routers that can only form relationships with other Level 2 routers. Routing information is exchanged between Level 1 routers and other Level 1 routers, and Level 2 routers only exchange information with other Level 2 routers. Level 1-2 routers exchange information with both levels and are used to connect the inter area routers with the intra area routers.

In OSPF, areas are delineated on the interface such that an area border router (ABR) is actually in two or more areas at once, effectively creating the borders between areas inside the ABR, whereas in IS-IS area borders are in between routers, designated as Level 2 or Level 1-2. The result is that an IS-IS router is only ever a part of a single area.

IS-IS also does not require Area 0 (Area Zero) to be the backbone area through which all inter-area traffic must pass. The logical view is that OSPF creates something of a spider web or star topology of many areas all attached directly to Area Zero and IS-IS by contrast creates a logical topology of a backbone of Level 2 routers with branches of Level 1-2 and Level 1 routers forming the individual areas.

IS-IS also differs from OSPF in the methods by which it reliably floods topology and topology change information through the network. However, the basic concepts are similar.^{[citation needed]}

OSPF has a larger set of extensions and optional features specified in the protocol standards. However IS-IS is more easy to expand: its use of type-length-value data allows engineers to implement support for new techniques without redesigning the protocol. For example, in order to support IPv6, the IS-IS protocol was extended to support a few additional TLVs, whereas OSPF required a new protocol draft (OSPFv3). In addition to that, IS-IS is less "chatty" and can scale to support larger networks. Given the same set of resources, IS-IS can support more routers in an area than OSPF. This has contributed to IS-IS as an ISP-scale protocol.^{[citation needed]}

The TCP/IP implementation, known as "Integrated IS-IS" or "Dual IS-IS", is described in RFC 1195.

================================================================================

D.V -> RIP                \

                                  +---->  IGP

L.S -> IS-IS / OSPF     /

BGP                           ------>  EGP