Prerequisites

A non-root user with sudo capabilities and a basic firewall are required to finish this article.
You can do this by following the instructions in our Initial Server Setup guide.

You can begin by logging into your Ubuntu 18.04 server as your sudo user and following the instructions provided below.

Step 1 — Installing and Configuring Redis

Installing Redis from the official Ubuntu repositories using apt is the best way to get the most recent version.

If you haven’t recently updated your local apt package cache, do so now:

sudo apt update

Then, type: Redis to install it.

sudo apt install Redis-server

All the necessary software will be installed in this process, including Redis.
The Redis configuration file generated automatically following the installation has one critical configuration update to make.

Using your chosen text editor, open this file:

sudo nano /etc/redis/redis.conf

Locate the supervised directive in the file.
This directive allows you to specify an init system to manage Redis as a service, giving you greater control over its operation..
By default, the supervised directive is turned off.
Change this to systemd since you’re running Ubuntu, which makes use of the systemd init system:

/etc/redis/redis.conf

Now that you’ve made that one update to the Redis configuration file, you’re done. Save and close it.
Restart Redis to take effect the modifications you made in the Redis configuration file:

$ sudo systemctl restart redis.service

Now that Redis is installed and configured, you may start using it.
It’s a good idea to verify if Redis is working properly before employing it.

Step 2 — Testing Redis

Make sure Redis is working as intended before making any more configuration changes, as you would with any freshly installed software.
In this section, we’ll cover a few strategies to ensure that Redis is functioning properly.

Ensure that the Redis service is up and operating by doing the following steps:

$ sudo systemctl status redis

If the command is running without any errors, the output will look like this:

Output● redis-server.service - Advanced key-value store
   Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-06-27 18:48:52 UTC; 12s ago
     Docs: http://redis.io/documentation,
           man:redis-server(1)
  Process: 2421 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=0/SUCCESS)
  Process: 2424 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
 Main PID: 2445 (redis-server)
    Tasks: 4 (limit: 4704)
   CGroup: /system.slice/redis-server.service
           └─2445 /usr/bin/redis-server 127.0.0.1:6379

Since Redis is already active and configured to run every time the server boots, you can see that it’s already running and ready to go.

Most frequent Redis use cases benefit from this option.
It’s also possible to configure a command to start Redis manually every time your server boots:

$ sudo systemctl disable redis

The command-line client can be used to verify that Redis is working properly.

$redis-cli

Use the ping command at the following prompt to see if you’re connected:

127. 0 . 0 . 1 : 6379 > ping

output : pong

As you can see, there’s still a working connection to the server.
Next, see if you have the ability to set keys by performing the following command:

127 . 0 . 0 . 1 : 6379>set test "It's working!"

OutputOK

Type the following to get the value:

127 . 0 . 0 . 1 : 6379> get test

Your cached value can be retrieved as long as everything is running smoothly:

Output"It's working!"

Having confirmed that you can retrieve the value, return to the shell by closing the Redis prompt.

127 . 0 . 0 . 1 : 6379> exit

Ultimately, we’ll see if data persists after restarting or shutting down Redis.
The first procedure is to restart Redis:

$ sudo systemctl restart redis

Once you’ve reconnected with the command-line client, make that your test value is still there:

$ redis-cli

127 . 0 . 0 . 1 : 6379> get test

It is important that the value of your key remains accessible:

Output"It's working!"

Once you’ve completed, re-enter the shell:

127 . 0 . 0 . 1 : 6379> exit

Redis is now fully operational and ready for you to utilise, as a result of this.
The problem is that certain of its default configuration settings are vulnerable to assault and unauthorised access to your server and its data, making it vulnerable to attack.
According to the official Redis website, these vulnerabilities can be mitigated via the following steps.
Redis will still function if you don’t follow these steps, however it is strongly suggested that you do so in order to increase the security of your system.

Step 3 — Binding to localhost

Redis, by default, may only be accessed from within the local network.
You may have modified the Redis configuration file to accept connections from any IP address if you followed a guide other than this one.
Localhost binding is far more secure than this.

Open the Redis configuration file and make the modifications to fix the problem:

$ sudo nano /etc/redis/redis.conf

This line should be uncommented (remove the # if it is there).

/etc/redis/redis.conf

bind 127.0.0.1 ::1

Close and save the file (CTRL + X, Y, ENTER) when you’re done.

Make sure that systemd is aware of your changes by restarting the service:

$ sudo systemctl restart redis

Locate the following line and remove the # if it appears:

/etc/redis/redis.conf

bind 127.0.0.1 ::1

Close and save the file (CTRL + X, Y, ENTER) when you’re done.

Make sure that systemd is aware of your changes by restarting the service:

$ sudo systemctl restart redis

Using the netstat command, you can verify that this update has taken effect:

$ sudo netstat -lnp | grep redis

Outputtcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      14222/redis-server  
tcp6       0      0 ::1:6379                :::*                    LISTEN      14222/redis-server  

According to the Redis configuration file, the redis-server application is bound to localhost (127.0.0.1).
Check to make sure that you uncommented the proper line and restart the Redis service again if you see a different IP address (0.0.0.0, for example).

It will be more difficult for bad actors to make requests or get access to your server now that your Redis installation is only listening in on localhost.
In contrast to this, Redis does not currently enforce authentication before making changes to its configuration or the data it contains.
This can be remedied by requiring Redis client users to authenticate themselves with a password before making modifications (redis-cli).

Step 4 — Configuring a Redis Password

The auth command, which requires clients to authenticate before accessing the database, can be enabled by configuring a Redis password, one of the two built-in security mechanisms.
So open the Redis.conf file in your favourite text editor and type in the password you’d like to use to access Redis.

$ sudo nano /etc/redis/redis.conf

Look for a statement in the SECURITY section that reads:

/etc/redis/redis.conf

# requirepass foobared

Remove the # and change foobared to a more safe password by uncommenting it.

Restart Redis after you’ve saved and closed the file and set the password:

$ sudo systemctl restart redis.service

Access the Redis command line and run the following command to verify that the password is correct.

$ redis-cli

Redis passwords can be tested using the following command sequence.
Setting a key value before authentication is the first command’s goal.

127 . 0 . 0 . 1 : 6379> set key1 10

In this case, Redis sends an error because you failed to authenticate.

Output(error) NOAUTH Authentication required.

The command prompt authenticates with the Redis configuration file’s password:

127 . 0 . 0 . 1 : 6379> auth your_redis_password

Redis acknowledges:

Output
OK

After that, the previous command will perform as planned:

127 . 0 . 0 . 1 : 6379> set key1 10

Output
OK

obtain the queries for the first key1
The new key’s value can be found in Redis.

127 . 0 . 0 . 1 : 6379> get key1

Output
"10"

Following authentication, you can exit the redis-cli and run commands in the Redis client:

127 . 0 . 0 . 1 : 6379> quit

The next topic we’ll cover is renaming Redis instructions, which, if executed maliciously or by accident, can do a lot of damage to your PC.

Step 5 — Renaming Dangerous Commands

Renaming or deactivating hazardous instructions in Redis is another security tool embedded into the database server.

Such commands can be used by unauthorised users to alter, delete, or otherwise erase your data.
In the same SECURITY section of the /etc/redis/redis.conf file, renaming or deactivating commands can be specified.

Commands such as FLUSHDB and FLUSHALL are regarded dangerous, as are KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF and SAVE. SPOP, SREM, RENAME and DEBUG are all considered risky.
Starting with renaming or deactivating all of the commands on that list is a smart place to begin improving the security of your Redis server.

Whether or whether a command should be disabled or renamed depends on your personal or site-specific requirements.
Disabling a command that could be misused if you know you won’t ever use it is fine.
As a result, renaming it may be in your best interests.

Redis commands can be enabled or disabled by reopening the Redis configuration file:

$ sudo nano  /etc/redis/redis.conf

An empty string (two quote marks with no letters between them) is all that is needed to disable a command.

/etc/redis/redis.conf

. . .

By renaming a command, it is also possible to fully remove it from the system.

an empty string:

#
rename-command FLUSHDB “”
rename-command FLUSHALL “”
rename-command DEBUG “”
. . .

This Redis installation will no longer be able to use FLUSHDB, FLUSHALL, or DEBUG if these directives are added and followed by empty strings.

You can rename a command by giving it a new name, such as the examples below.
A command’s name should be tough for others to decipher, yet simple for you to remember.

. . .

rename-command CONFIG “”

rename-command SHUTDOWN SHUTDOWN_MENOT
rename-command CONFIG ASC12_CONFIG
. . .

Renaming the SHUTDOWN and CONFIG commands to SHUTDOWN MENOT and ASC12 CONFIG, respectively, is done in these instances.

Close the document and save your work.

After renaming a command, restart Redis to apply the change:

$ sudo systemctl restart redis.service

The Redis client can be used to see if these commands were successfully updated:

$ redis-cli

Then, authenticate:

127 . 0 . 0 . 1 : 6379> auth your_redis_password

Output
OK

In the prior example, you renamed the command CONFIG to ASC12 CONFIG.
Initially, you may want to use the original CONFIG command.
Because you’ve renamed it, it should fail:

127 . 0 . 0 . 1 : 6379> config get requirepass

Output
(error) ERR unknown command 'config'

The renamed command, on the other hand, will work.
It doesn’t matter if it’s capitalised or lowercase:

127 . 0 . 0 . 1 : 6379> asc12_config get requirepass

Anyone who runs Redis’ config command can access the installation’s underlying configuration file.
In combination with get and a directive from the configuration file, the command will return that directive and its current value:.

Output1) "requirepass"
2) "your_redis_password"

Finally, you can exit from redis-cli:

127 . 0 . 0 . 1 : 6379> exit

If you’re already using the Redis command line and then restart Redis, you’ll need to re-authenticate to continue using the service.
If you type a command, you’ll get this error:

Output
NOAUTH Authentication required.

Conclusion

After completing this course, you should be able to set up Redis, verify that it is working properly, and use the security measures built into Redis to protect it from malicious actors.

The Redis-specific security mechanisms we’ve implemented can be easily bypassed once someone has logged in to your server.
That’s why it’s so vital to have a firewall in place on your Redis server, as it makes it nearly impossible for hackers to get past that barrier.

HelptoInstall presents Redis Installation service at a low-cost. We have deployed our experts 24/7.

The post How To Install Redis on Ubuntu 18.04 ? appeared first on Hostnats.

ElasticSearch’s first public release version was 0.4 in February 2010, and it’s developed by Shay Banon.

ElasticSearch takes in unstructured data from different locations, stores and indexes it according to user-specified mapping, and makes it searchable.

ElasticSearch analysis all types of data including text, numerical, geospatial, structured, and unstructured.

ElasticSearch search engine technology help in extracting meaning from data at scale.

For some problems, ElasticSeach can give you an answer back in milliseconds while other systems like Hadoop or Apache Spark might take hours.

Let’s see what are the pros and cons of Elasticsearch that the experts have experienced.

Pros and Cons of Elasticsearch

Pros

• Since it has been developed in Java, Elasticsearch is compatible to run on every platform.
• Compared to Apache Solr, multi-tenancy can be handled by Elasticsearch in an ease.
• There is no need to pay lisence cost for downloading Elasticsearch, because it is an open source.
• Elasticsearch supports all types of document, except for those who do not support text rendering.
• Elasticsearch is documented in several languages. Hence, people from different countries or regions can use it in their languages.
• There is a gateway concept for Elasticsearch. With the help of the gateway, we can create full backups easily.
• Since it is a real time search engine, it takes only a second before the added document is searchable in the particular engine.
• Since this search engine is document oriented, it makes easy to scale up in bigger organization.

Cons

• Once in while, a Split-brain problem occurs in Elasticsearch.
• Elasticsearch doesn’t have multilanguage support. It makes handling request and response data harder.
• Elasticsearch is indeed a flexible and powerful data storage search engine, but it is harder to learn.
• Data store of Elasticsearch is not that impressive, as there are other efficient options such as MongoDB, Hadoop etc. It has good performance in terms of small use cases. But if you are having the use of steaming TB’s data per day, then it is not a great option. It may chokes or loses your valuable data.

HelptoInstall presents you with Elacticsearch Installation Service at a cost-effective pricing scheme. We have deployed our Experts 24/7 for the services.

The post What is Elasticsearch? appeared first on Hostnats.

MySQL is an Open-Source Database Management System and Michael Widenius was the Co-Founder and its initial release was in the year 1995. Later, MySQL was acquired by Oracle Corporation. MySQL stands for the co-founder Michael Widenius’s daughter’s name and SQL stands for Structural Query Language. SQL is a language that programmers use for creating and managing data from the database. Since MySQL is an Open-Source Software, it’s free for the users. MySQL is renowned for its capability to handle a large volume of data. Since MySQL was acquired by Oracle Corporation, some issues were taken place with the usage of the database, therefore, MariaDB was developed.

MariaDB

MariaDB was developed by a community named MariaDB Foundation in the year 2009. It is an Open-Source software intended for free. MariaDB is a compatible drop-in replacement for MySQL database technology. Since MariaDB was made intending for better performance than MySQL, MariaDB has a high number of extra new features and that made user orientation and performance better than MySQL.

Difference Between MariaDB and MySQL

• MariaDB is faster than MySQL.
• MySQL uses specific proprietary code when it comes to Enterprise Edition whreas MariaDB is Open-Source.
• MariaDB is not supporting Dynamic Column and Data Masking whilst MySQL supports both.
• Replication is faster in MariaDB whereas it is slower in MySQL.
• Apparently, MariaDB is having 12 storage engine while MySQL has less storage engines.
• Connection pool of MariaDB is massive, it is supporting upto 200,000+ connections while connection pool of MySQL is smaller.

MariaDB has not yet outplayed MySQL by its upper hand. Though, a lot of the leading Corporate Companies are still preferring MySQL due to its simplicity.

If you aren’t a database software expert, there is a risk in installing or transferring both programmes without the help of a professional. Don’t put your valuable data at risk!

Check into https://www.helptoinstall.com/ for Cloud, Server Software Installation, and Migration Services.

The post MySQL vs MariaDB appeared first on Hostnats.