Protocols & Architecture: SOAP, REST, SOA, WEBSOCKET, SOCKETS, IO, HTTP, TCP, UDP, Micro-services : Clearance of confusing state at one place

WebSocket vs REST

Key Differences between WebSocket vs REST:

Both WebSocket and REST are popular choices in the market; let us discuss some of the major Difference Between WebSocket vs REST :

1. WebSocket is a low-level protocol, based on the concept of socket and port, which are the underlying transport mechanism whereas REST is based on CRUD operation.
2. WebSocket require the use of IP address and Port details, which are lower level details for any application whereas RESTful application needs to design operation based on verbs, and HTTP based.
3. WebSocket is bi-directional in nature i.e. both way operation from client to server and vice versa is possible whereas REST follows a uni-directional approach.
4. WebSocket approach is ideal for real-time scalable application, whereas REST is better suited for the scenario with lots of getting request.
5. WebSocket is a stateful protocol whereas REST is based on stateless protocol i.e. client does not need to know about the server and same hold true for the server.
6. WebSocket connection can scale vertically on a single server whereas REST, which is HTTP based can scale horizontally.
7. WebSocket is ideal for a scenario where high loads are a part of game i.e. real-time scalable chat application whereas REST is better fitted for occasional communication, in a typical GET request scenario to call RESTful APIs.
8. WebSocket works better, where client-server communicates over the same TCP connection for the life of web socket connection whereas, for HTTP request, a new TCP connection is initiated.
9. WebSocket communication allows client and server to talk independently of each other whereas with the REST based approach, either client is talking to the client or server is talking to the client at any given time.
10. WebSocket communication cost is lower whereas REST-based communication is comparatively higher end on the cost.
    
    
    

    The basis Of Comparison Between WebSocket vs REST	WebSocket	REST
    HTTP	Use of HTTP occurs in initial connection.	HTTP is a common protocol in RESTful web services.
    Communication	Bi-directional in nature.	Uni-directional in nature.
    Nature	Socket-based concept.	Resources based concept, rather than commands.
    Scenario	Real-time chat application.	Lots of getting request.
    Dependency	Rely on IP address and Port number.	Based on the HTTP protocol and uses HTTP methods to relay data.
    Cost	Cost of communication is lower.	Cost of communication is comparatively higher than WebSocket.
    Performance	Better with high loads.	Great for occasional communication.
    State	WebSocket is a stateful protocol.	REST is based on HTTP which is a stateless protocol.

Conclusion – WebSocket vs REST:

REST is so far the most standardized way of structuring the web APIs for the request. Most of the web application, tend to go with the RESTful approach. Verb-based action i.e. create, read, update or delete operation are executed successfully over HTTP protocol. There are certain benefits which come along with the use of HTTP protocol, client and server need not know about each other. Any operation done on the client side won’t hamper the server-side operation and the same holds true for server-side functionality.

WebSocket, on the other hand, is based on the lower-level concept, like socket and port. Application IP address and port are required in this medium of communication. Moreover, a single TCP connection can be shared for web socket communication between client and server. Also, it is a stateful protocol, unlike HTTP which is stateless in nature.

Hence, usage of REST over WebSocket or vice versa depends upon the type of application and scenario. For a real-time, scalable application, WebSocket is the ideal choice, less costly as compared to REST. Any application with lots of CRUD operation invites the use of RESTful style. At the end of the day, it is the requirement and scenario, which would decide the usage of WebSocket vs REST.

Serverless Architectures

Serverless Architecture:

Serverless architectures refer to applications that significantly depend on third-party services (knows as Backend as a Service or “BaaS”) or on custom code that’s run in ephemeral containers (Function as a Service or “FaaS”), the best known vendor host of which currently is AWS Lambda. By using these ideas, and by moving much behavior to the front end, such architectures remove the need for the traditional ‘always on’ server system sitting behind an application. Depending on the circumstances, such systems can significantly reduce operational cost and complexity at a cost of vendor dependencies and (at the moment) immaturity of supporting services

Serverless Architecture

Maintain Old Kernels While Performing Kernel Upgrade - Redhat

Some might call me paranoid, but I get nervous when my package manager automatically removes a kernel.

================================================================================ Package Arch Version Repository Size ================================================================================ Installing: kernel x86_64 2.6.35.13-92.fc14 updates 22 M Removing: kernel x86_64 2.6.35.11-83.fc14 @updates 104 M   Transaction Summary ================================================================================ Install 1 Package(s) Remove 1 Package(s)

Redhat default behavior is to keep three kernels: the latest one and the two previous versions. However, this behavior may be counter-productive if you compile your own modules, or if you have compatibility issues with subsequent kernel versions.
You can change how yum handles kernel packages with some simple changes to your /etc/yum.conf. The installonly_limit option controls how many old packages are kept:

installonly_limit Number of packages listed in installonlypkgs to keep installed at the same time. Setting to 0 disables this feature. Default is ‘0’.

I disabled the functionality altogether by setting installonly_limit to 0:

#installonly_limit=3 installonly_limit=0

It’s important to keep in mind that you will need to purge these packages from your system yourself now. Kernel packages can occupy a fair amount of disk space, so make a note to go back and clean them up when you no longer need them.

Fedora Directory Server: 389 Directory Server

Fedora Directory Server

389 Directory Server formerly the Fedora Directory Server is an enterprise-class open source LDAP server for Linux.

Server Side configuration (Installing 389 Directory Server):

1.       Type in the command below to update your Red Hat Enterprise Linux 5 or Centos 5 to version 5.3 or higher. Version 5.3 and above is required to run the 389 Directory Server.

# yum update

1.       Install 389 Directory Server by typing in the commands below in a terminal window. This is the content of fedora-ds.repo.

# cd /etc/yum.repos.d

# wget www.linuxmail.info/files/fedora-ds.repo

# yum install 389-ds openldap-clients

2.       Create a new user and group named fds. This account will be used to run the fds service.

3.       Type in setup-ds-admin.pl in a terminal window to setup 389 Directory Server.

# setup-ds-admin.pl

Once we run this command use following installation logs to choose correct option.

[root@mail ~]# setup-ds-admin.pl

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

This program will set up the 389 Directory and Administration Servers.

It is recommended that you have "root" privilege to set up the software.

Tips for using this program:

  - Press "Enter" to choose the default and go to the next screen

  - Type "Control-B" then "Enter" to go back to the previous screen

  - Type "Control-C" to cancel the setup program

Would you like to continue with set up? [yes]: ↵

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

BY SETTING UP AND USING THIS SOFTWARE YOU ARE CONSENTING TO BE BOUND BY

AND ARE BECOMING A PARTY TO THE AGREEMENT FOUND IN THE

LICENSE.TXT FILE. IF YOU DO NOT AGREE TO ALL OF THE TERMS

OF THIS AGREEMENT, PLEASE DO NOT SET UP OR USE THIS SOFTWARE.

Do you agree to the license terms? [no]: yes

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

Your system has been scanned for potential problems, missing patches,

etc.  The following output is a report of the items found that need to

be addressed before running this software in a production

environment.

389 Directory Server system tuning analysis version 10-AUGUST-2007.

NOTICE : System is i686-unknown-linux2.6.18-53.el5 (1 processor).

WARNING: 376MB of physical memory is available on the system. 1024MB is recommended for best performance on large production system.

NOTICE : The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds

(120 minutes).  This may cause temporary server congestion from lost

client connections.

WARNING: There are only 1024 file descriptors (hard limit) available, which

limit the number of simultaneous connections.  

WARNING: There are only 1024 file descriptors (soft limit) available, which

limit the number of simultaneous connections.  

Would you like to continue? [no]: yes

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

Choose a setup type:

   1. Express

       Allows you to quickly set up the servers using the most

       common options and pre-defined defaults. Useful for quick

       evaluation of the products.

   2. Typical

       Allows you to specify common defaults and options.

   3. Custom

       Allows you to specify more advanced options. This is 

       recommended for experienced server administrators only.

To accept the default shown in brackets, press the Enter key.

Choose a setup type [2]: ↵

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

Enter the fully qualified domain name of the computer

on which you're setting up server software. Using the form

.

Example: eros.example.com.

To accept the default shown in brackets, press the Enter key.

Computer name [fds.noida.up]: ↵

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

The servers must run as a specific user in a specific group.

It is strongly recommended that this user should have no privileges

on the computer (i.e. a non-root user).  The setup procedure

will give this user/group some permissions in specific paths/files

to perform server-specific operations.

If you have not yet created a user and group for the servers,

create this user and group using your native operating

system utilities.

System User [nobody]: fds

System Group [nobody]: fds

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

Server information is stored in the configuration directory server.

This information is used by the console and administration server to

configure and manage your servers.  If you have already set up a

configuration directory server, you should register any servers you

set up or create with the configuration server.  To do so, the

following information about the configuration server is required: the

fully qualified host name of the form

.(e.g. hostname.example.com), the port number

(default 389), the suffix, the DN and password of a user having

permission to write the configuration information, usually the

configuration directory administrator, and if you are using security

(TLS/SSL).  If you are using TLS/SSL, specify the TLS/SSL (LDAPS) port

number (default 636) instead of the regular LDAP port number, and

provide the CA certificate (in PEM/ASCII format).

If you do not yet have a configuration directory server, enter 'No' to

be prompted to set up one.

Do you want to register this software with an existing

configuration directory server? [no]: ↵

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

Please enter the administrator ID for the configuration directory

server.  This is the ID typically used to log in to the console.  You

will also be prompted for the password.

Configuration directory server

administrator ID [admin]: ↵

Password: 

Password (confirm): 

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

The information stored in the configuration directory server can be

separated into different Administration Domains.  If you are managing

multiple software releases at the same time, or managing information

about multiple domains, you may use the Administration Domain to keep

them separate.

If you are not using administrative domains, press Enter to select the

default.  Otherwise, enter some descriptive, unique name for the

administration domain, such as the name of the organization

responsible for managing the domain.

Administration Domain [noida.up]: ↵

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

The standard directory server network port number is 389.  However, if

you are not logged as the superuser, or port 389 is in use, the

default value will be a random unused port number greater than 1024.

If you want to use port 389, make sure that you are logged in as the

superuser, that port 389 is not in use.

Directory server network port [389]: ↵

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

Each instance of a directory server requires a unique identifier.

This identifier is used to name the various

instance specific files and directories in the file system,

as well as for other uses as a server instance identifier.

Directory server identifier [fds]: ↵

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

The suffix is the root of your directory tree.  The suffix must be a valid DN.

It is recommended that you use the dc=domain component suffix convention.

For example, if your domain is example.com,

you should use dc=example,dc=com for your suffix.

Setup will create this initial suffix for you,

but you may have more than one suffix.

Use the directory server utilities to create additional suffixes.

Suffix [dc=noida, dc=up]: ↵

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

Certain directory server operations require an administrative user.

This user is referred to as the Directory Manager and typically has a

bind Distinguished Name (DN) of cn=Directory Manager.

You will also be prompted for the password for this user.  The password must

be at least 8 characters long, and contain no spaces.

Directory Manager DN [cn=Directory Manager]: ↵

Password: 

Password (confirm): 

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

The Administration Server is separate from any of your web or application

servers since it listens to a different port and access to it is

restricted.

Pick a port number between 1024 and 65535 to run your Administration

Server on. You should NOT use a port number which you plan to

run a web or application server on, rather, select a number which you

will remember and which will not be used for anything else.

Administration port [9830]: ↵

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

The interactive phase is complete.  The script will now set up your

servers.  Enter No or go Back if you want to change something.

Are you ready to set up your servers? [yes]: ↵

Creating directory server . . .

Your new DS instance 'mail' was successfully created.

Creating the configuration directory server . . .

Beginning Admin Server creation . . .

Creating Admin Server files and directories . . .

Updating adm.conf . . .

Updating admpw . . .

Registering admin server with the configuration directory server . . .

Updating adm.conf with information from configuration directory server . . .

Updating the configuration for the httpd engine . . .

Starting admin server . . .

The admin server was successfully started.

Admin server was successfully created, configured, and started.

Exiting . . .

Log file is '/tmp/setupcT78dr.log'

4.       Setup the 389 Directory Server SSL by executing the commands below in a terminal window.

# wget http://github.com/richm/scripts/blob/master%2Fsetupssl2.sh?raw=true -O setupssl2.sh

# chmod +x setupssl2.sh

# ./setupssl2.sh /etc/dirsrv/slapd-fds

Replace fds with your own server instance. During setup, you will be asked for the password of directory manager.

5.       Start the dirsrv and dirsrv-admin service.

Launching the 389 Management Console:

1.       From a terminal window, type in 389-console. This will launch the 389 Management Console Login window.  

User ID

cn=directory manager

Password

the directory manager password

Administration URL

localhost:9830

2.       Click the + sign corresponding to your server. Next, click the + sign corresponding to Server Group and click Directory Server. Finally, click the Open button in the Directory Server page.

3.       Click the Directory tab.

4.       Click the folder corresponding to your domain.

Creating a New User

1.       Right click your domain, select New and click User.

2.       In the Create New User window, fill in the user information and click Ok when you are done.

Creating a New Group

1.       Right click your domain, select New and click Group.

2.       In the Create New Group window, fill in the group information.

3.       Add the member users in the Members section. Click Ok when you are done.

Creating a New Organizational Unit

1.       Right click your domain, select New and click Organizational Unit.

2.       In the Create New Organizational Unit window, fill in the organizational unit information and click Ok when you are done.

Client Side configuration (authenticating Linux client with 389 directory server):

1.       Click System, select Administration and click Authentication. This will launch the Authentication Configuration window.

2.       Check Enable LDAP Support and click the Configure LDAP button.

3.       Fill in the LDAP Search Base DN and LDAP Server fields. Click Ok when you are done.

4.       Click the Authentications tab and check Enable LDAP Support.

5.       Click the Options tab and check Local authorization is sufficient for local users and Create home directories on the first login. Click Ok when you are done.

6.       Type in getent passwd in a terminal window. You should see your LDAP user accounts.

# getent passwd

Fedora Directory Server

389 Directory Server formerly the Fedora Directory Server is an enterprise-class open source LDAP server for Linux.

Server Side configuration (Installing 389 Directory Server):

1.       Type in the command below to update your Red Hat Enterprise Linux 5 or Centos 5 to version 5.3 or higher. Version 5.3 and above is required to run the 389 Directory Server.

# yum update

1.       Install 389 Directory Server by typing in the commands below in a terminal window. This is the content of fedora-ds.repo.

# cd /etc/yum.repos.d

# wget www.linuxmail.info/files/fedora-ds.repo

# yum install 389-ds openldap-clients

2.       Create a new user and group named fds. This account will be used to run the fds service.

3.       Type in setup-ds-admin.pl in a terminal window to setup 389 Directory Server.

# setup-ds-admin.pl

Once we run this command use following installation logs to choose correct option.

[root@mail ~]# setup-ds-admin.pl

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

This program will set up the 389 Directory and Administration Servers.

It is recommended that you have "root" privilege to set up the software.

Tips for using this program:

  - Press "Enter" to choose the default and go to the next screen

  - Type "Control-B" then "Enter" to go back to the previous screen

  - Type "Control-C" to cancel the setup program

Would you like to continue with set up? [yes]: ↵

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

BY SETTING UP AND USING THIS SOFTWARE YOU ARE CONSENTING TO BE BOUND BY

AND ARE BECOMING A PARTY TO THE AGREEMENT FOUND IN THE

LICENSE.TXT FILE. IF YOU DO NOT AGREE TO ALL OF THE TERMS

OF THIS AGREEMENT, PLEASE DO NOT SET UP OR USE THIS SOFTWARE.

Do you agree to the license terms? [no]: yes

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

Your system has been scanned for potential problems, missing patches,

etc.  The following output is a report of the items found that need to

be addressed before running this software in a production

environment.

389 Directory Server system tuning analysis version 10-AUGUST-2007.

NOTICE : System is i686-unknown-linux2.6.18-53.el5 (1 processor).

WARNING: 376MB of physical memory is available on the system. 1024MB is recommended for best performance on large production system.

NOTICE : The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds

(120 minutes).  This may cause temporary server congestion from lost

client connections.

WARNING: There are only 1024 file descriptors (hard limit) available, which

limit the number of simultaneous connections.  

WARNING: There are only 1024 file descriptors (soft limit) available, which

limit the number of simultaneous connections.  

Would you like to continue? [no]: yes

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

Choose a setup type:

   1. Express

       Allows you to quickly set up the servers using the most

       common options and pre-defined defaults. Useful for quick

       evaluation of the products.

   2. Typical

       Allows you to specify common defaults and options.

   3. Custom

       Allows you to specify more advanced options. This is 

       recommended for experienced server administrators only.

To accept the default shown in brackets, press the Enter key.

Choose a setup type [2]: ↵

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

Enter the fully qualified domain name of the computer

on which you're setting up server software. Using the form

.

Example: eros.example.com.

To accept the default shown in brackets, press the Enter key.

Computer name [fds.noida.up]: ↵

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

The servers must run as a specific user in a specific group.

It is strongly recommended that this user should have no privileges

on the computer (i.e. a non-root user).  The setup procedure

will give this user/group some permissions in specific paths/files

to perform server-specific operations.

If you have not yet created a user and group for the servers,

create this user and group using your native operating

system utilities.

System User [nobody]: fds

System Group [nobody]: fds

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

Server information is stored in the configuration directory server.

This information is used by the console and administration server to

configure and manage your servers.  If you have already set up a

configuration directory server, you should register any servers you

set up or create with the configuration server.  To do so, the

following information about the configuration server is required: the

fully qualified host name of the form

.(e.g. hostname.example.com), the port number

(default 389), the suffix, the DN and password of a user having

permission to write the configuration information, usually the

configuration directory administrator, and if you are using security

(TLS/SSL).  If you are using TLS/SSL, specify the TLS/SSL (LDAPS) port

number (default 636) instead of the regular LDAP port number, and

provide the CA certificate (in PEM/ASCII format).

If you do not yet have a configuration directory server, enter 'No' to

be prompted to set up one.

Do you want to register this software with an existing

configuration directory server? [no]: ↵

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

Please enter the administrator ID for the configuration directory

server.  This is the ID typically used to log in to the console.  You

will also be prompted for the password.

Configuration directory server

administrator ID [admin]: ↵

Password: 

Password (confirm): 

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

The information stored in the configuration directory server can be

separated into different Administration Domains.  If you are managing

multiple software releases at the same time, or managing information

about multiple domains, you may use the Administration Domain to keep

them separate.

If you are not using administrative domains, press Enter to select the

default.  Otherwise, enter some descriptive, unique name for the

administration domain, such as the name of the organization

responsible for managing the domain.

Administration Domain [noida.up]: ↵

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

The standard directory server network port number is 389.  However, if

you are not logged as the superuser, or port 389 is in use, the

default value will be a random unused port number greater than 1024.

If you want to use port 389, make sure that you are logged in as the

superuser, that port 389 is not in use.

Directory server network port [389]: ↵

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

Each instance of a directory server requires a unique identifier.

This identifier is used to name the various

instance specific files and directories in the file system,

as well as for other uses as a server instance identifier.

Directory server identifier [fds]: ↵

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

The suffix is the root of your directory tree.  The suffix must be a valid DN.

It is recommended that you use the dc=domain component suffix convention.

For example, if your domain is example.com,

you should use dc=example,dc=com for your suffix.

Setup will create this initial suffix for you,

but you may have more than one suffix.

Use the directory server utilities to create additional suffixes.

Suffix [dc=noida, dc=up]: ↵

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

Certain directory server operations require an administrative user.

This user is referred to as the Directory Manager and typically has a

bind Distinguished Name (DN) of cn=Directory Manager.

You will also be prompted for the password for this user.  The password must

be at least 8 characters long, and contain no spaces.

Directory Manager DN [cn=Directory Manager]: ↵

Password: 

Password (confirm): 

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

The Administration Server is separate from any of your web or application

servers since it listens to a different port and access to it is

restricted.

Pick a port number between 1024 and 65535 to run your Administration

Server on. You should NOT use a port number which you plan to

run a web or application server on, rather, select a number which you

will remember and which will not be used for anything else.

Administration port [9830]: ↵

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

The interactive phase is complete.  The script will now set up your

servers.  Enter No or go Back if you want to change something.

Are you ready to set up your servers? [yes]: ↵

Creating directory server . . .

Your new DS instance 'mail' was successfully created.

Creating the configuration directory server . . .

Beginning Admin Server creation . . .

Creating Admin Server files and directories . . .

Updating adm.conf . . .

Updating admpw . . .

Registering admin server with the configuration directory server . . .

Updating adm.conf with information from configuration directory server . . .

Updating the configuration for the httpd engine . . .

Starting admin server . . .

The admin server was successfully started.

Admin server was successfully created, configured, and started.

Exiting . . .

Log file is '/tmp/setupcT78dr.log'

4.       Setup the 389 Directory Server SSL by executing the commands below in a terminal window.

# wget http://github.com/richm/scripts/blob/master%2Fsetupssl2.sh?raw=true -O setupssl2.sh

# chmod +x setupssl2.sh

# ./setupssl2.sh /etc/dirsrv/slapd-fds

Replace fds with your own server instance. During setup, you will be asked for the password of directory manager.

5.       Start the dirsrv and dirsrv-admin service.

Launching the 389 Management Console:

1.       From a terminal window, type in 389-console. This will launch the 389 Management Console Login window.  

User ID

cn=directory manager

Password

the directory manager password

Administration URL

localhost:9830

2.       Click the + sign corresponding to your server. Next, click the + sign corresponding to Server Group and click Directory Server. Finally, click the Open button in the Directory Server page.

3.       Click the Directory tab.

4.       Click the folder corresponding to your domain.

Creating a New User

1.       Right click your domain, select New and click User.

2.       In the Create New User window, fill in the user information and click Ok when you are done.

Creating a New Group

1.       Right click your domain, select New and click Group.

2.       In the Create New Group window, fill in the group information.

3.       Add the member users in the Members section. Click Ok when you are done.

Creating a New Organizational Unit

1.       Right click your domain, select New and click Organizational Unit.

2.       In the Create New Organizational Unit window, fill in the organizational unit information and click Ok when you are done.

Client Side configuration (authenticating Linux client with 389 directory server):

1.       Click System, select Administration and click Authentication. This will launch the Authentication Configuration window.

2.       Check Enable LDAP Support and click the Configure LDAP button.

3.       Fill in the LDAP Search Base DN and LDAP Server fields. Click Ok when you are done.

4.       Click the Authentications tab and check Enable LDAP Support.

5.       Click the Options tab and check Local authorization is sufficient for local users and Create home directories on the first login. Click Ok when you are done.

6.       Type in getent passwd in a terminal window. You should see your LDAP user accounts.

# getent passwd