One place for hosting & domains

      Configure

      How To Configure HAProxy Logging with Rsyslog on CentOS 8 [Quickstart]


      Introduction

      HAProxy, which stands for High Availability Proxy, is a widely used TCP and HTTP-based proxy server that runs on Linux, Solaris, and FreeBSD. It is used to load balance applications by distributing requests between multiple servers, and to ensure that applications are highly available for users.

      By default on many CentOS 8 installations, HAProxy is not configured to write its log output to a file. This quickstart tutorial will explain how to configure HAProxy logging with Rsyslog by using a Unix domain socket for reliability, speed, and security.

      Prerequisites

      To complete this tutorial, you will need a server running CentOS 8. This server should have a non-root user with administrative privileges. To set this up, follow the Initial Server Setup guide for CentOS 8 tutorial.

      Step 1 — Installing and Enabling HAProxy

      To install HAProxy, run the following dnf command:

      When you are prompted Is this ok [y/N]: enter y and press RETURN to install the package.

      Once you have installed HAProxy, enable and start it using the systemctl command:

      • sudo systemctl enable haproxy.service

      You should receive the following output:

      Output

      Created symlink /etc/systemd/system/multi-user.target.wants/haproxy.service → /usr/lib/systemd/system/haproxy.service.

      With the HAProxy service now enabled, you can start it up to ensure that it runs with a default configuration on your server:

      • sudo systemctl start haproxy.service

      Next examine HAProxy’s status to make sure it is running:

      • sudo systemctl status haproxy.service

      You should receive output like the following. Note the highlighted active (running) portion of the output. If your server shows the same highlighted section then HAProxy is running correctly on your server and you can proceed with configuring logging.

      Output

      ● haproxy.service - HAProxy Load Balancer Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2020-09-09 21:16:39 UTC; 4min 39s ago Process: 21340 ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q (code=exited, status=0/SUCCESS) Main PID: 21341 (haproxy) Tasks: 2 (limit: 2881) Memory: 2.7M CGroup: /system.slice/haproxy.service ├─21341 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid . . .

      If your output is different, or the status shows something like Active: failed, then follow the troubleshooting steps in the HAproxy Common Errors Series Introduction tutorial to determine what is preventing HAProxy from starting correctly.

      Once you have confirmed that HAProxy is enabled and running, you can continue to the next step, which is configuring HAProxy’s logging directives.

      Step 2 — Configuring HAProxy Logging Directives

      To configure HAProxy’s logging directives, open /etc/haproxy/haproxy.cfg in vi or your preferred editor:

      • sudo vi /etc/haproxy/haproxy.cfg

      Press i to switch to INSERT mode, then find the line log 127.0.0.1 local2 and comment it out by adding a # character to the beginning of the line, as highlighted in the following example:

      /etc/haproxy/haproxy.cfg

      . . .
      # 2) configure local2 events to go to the /var/log/haproxy.log
      #   file. A line like the following can be added to
      #   /etc/sysconfig/syslog
      #
      #    local2.*                       /var/log/haproxy.log
      #
          #log         127.0.0.1 local2
      
          chroot      /var/lib/haproxy
          pidfile     /var/run/haproxy.pid
      . . .
      

      Now add a line directly after the commented out line with the following contents:

          log         /dev/log local0
      

      The entire section of /etc/haproxy/haproxy.cfg that you edited should contain the following lines:

      /etc/haproxy/haproxy.cfg

      . . .
      #    local2.*                       /var/log/haproxy.log
      #
           #log         127.0.0.1 local2
           log         /dev/log local0
      
           chroot      /var/lib/haproxy
           pidfile     /var/run/haproxy.pid
      . . .
      

      The chroot line is important, because it restricts the HAProxy process to accessing files in the /var/lib/haproxy directory only. The log /dev/log local0 line will create a file inside that directory that Rsyslog will use to collect log entries from.

      Once you are finished editing the log lines in /etc/haproxy/haproxy.cfg, save and close the file by pressing ESC, typing :wq, and pressing ENTER.

      The last step that you need to complete in this section is to create the /var/lib/haproxy/dev directory since it does not exist by default.

      Create the directory using the mkdir command and then restart HAProxy:

      • sudo mkdir /var/lib/haproxy/dev
      • sudo systemctl restart haproxy.service

      You have now configured HAProxy to send its logs to a Unix domain socket that resides in /var/lib/haproxy/dev/log. In the next step, you will configure Rsyslog to create and access the socket.

      Step 3 — Configuring Rsyslog to Collect HAProxy Logs

      Rsyslog’s default configuration on CentOS 8 does not handle HAProxy logs. To collect logs from the HAProxy service, open a new file /etc/rsyslog.d/99-haproxy.conf using vi or your preferred editor:

      • sudo vi /etc/rsyslog.d/99-haproxy.conf

      Press i to switch to INSERT mode, then paste the following lines into the file:

      /etc/rsyslog.d/99-haproxy.conf

      $AddUnixListenSocket /var/lib/haproxy/dev/log
      
      # Send HAProxy messages to a dedicated logfile
      :programname, startswith, "haproxy" {
        /var/log/haproxy.log
        stop
      }
      

      The $AddUnixListenSocket directive tells Rsyslog to create a Unix domain socket in the specified location, in this case /var/lib/haproxy/dev/log. The :programname, startswith, "haproxy" section specifies the file where Rsyslog will write the log entries to that it collects from the socket.

      Once you are finished editing /etc/rsyslog.d/99-haproxy.conf, save and close the file by pressing ESC, typing :wq, and pressing ENTER.

      You have now configured Rsyslog to read log entries from the Unix domain socket in /var/lib/haproxy/dev/log and write them to a log file in /var/log/haproxy.log.

      However, before restarting Rsyslog you will need to determine if SELinux is enforcing access control on your CentOS 8 system.

      To check SELinux’s current policy, run the following:

      You will receive one of the following outputs:

      • Enforcing – In this mode, SELinux is enforcing access controls on your system. You will need to complete the following optional Step 4 — Configuring SELinux section.
      • Permissive – In this case, SELinux logs all access attempts to its log file, but does not enforce access controls on your system.
      • Disabled – If SELinux is disabled, then it is not logging or enforcing any access control policies on your system.

      If the getenforce command returned either Permissive or Disabled, then you can restart Rsyslog with the following command:

      • sudo systemctl restart rsyslog

      Once you restart Rsyslog, you will be able to view logs in the /var/log/haproxy.log file that you configured in /etc/rsyslog.d/99-haproxy.conf. Proceed to Step 5 — Testing HAProxy Logging to make sure that everything is working as expected.

      Otherwise, if your system is running SELinux in Enforcing mode, then the next section of this tutorial explains how to add a module to allow Rsyslog and HAProxy to communicate with each other over their shared Unix domain socket.

      Step 4 — (Optional) Configuring SELinux

      If your CentOS 8 system is configured with SELinux in Enforcing mode, then you will need to allow Rsyslog access to HAProxy’s chroot directory. Allowing this access will let Rsyslog create the Unix domain socket that HAproxy will send its logs to.

      If you are not familiar with SELinux, this tutorial series An Introduction to SELinux on CentOS 7 will help you learn how to manage and interact with SELinux. Although it is written for CentOS 7, the principles and commands in the series are equally applicable to CentOS 8.

      To enable Rsyslog and HAProxy access to their shared socket, the first task is to create a Type Enforcement policy file. Open a new file called rsyslog-haproxy.te in vi or your preferred editor:

      Press i to switch to INSERT mode, then paste the following lines into the file:

      rsyslog-haproxy.te

      module rsyslog-haproxy 1.0;
      
      require {
          type syslogd_t;
          type haproxy_var_lib_t;
          class dir { add_name remove_name search write };
          class sock_file { create setattr unlink };
      }
      
      #============= syslogd_t ==============
      allow syslogd_t haproxy_var_lib_t:dir { add_name remove_name search write };
      allow syslogd_t haproxy_var_lib_t:sock_file { create setattr unlink };
      

      The first line defines the module name and version. The require portion tells the SELinux module loader about the types and classes that are required for the policy to be loaded as a module. The last two lines are the rules that allow Rsyslog access to HAProxy’s chroot and socket file respectively.

      When you are done editing the file, save and close it by pressing ESC, typing :wq, and pressing ENTER.

      Next, run the following command to install the checkpolicy package, which contains the checkmodule utility that you will use to turn the Type Enforcement file into an SELinux module.

      • sudo dnf install checkpolicy

      Now that you have the checkmodule tool installed, the next step is to compile the module and then load it into SELinux. Run the following to compile the Type Enforcement file into an SELinux module:

      • checkmodule -M -m rsyslog-haproxy.te -o rsyslog-haproxy.mod

      Next, run semodule_package to generate a complete policy package that SELinux can load into the Linux kernel:

      • semodule_package -o rsyslog-haproxy.pp -m rsyslog-haproxy.mod

      The final step is to load the package that you generated into the Linux kernel using the semodule command:

      • sudo semodule -i rsyslog-haproxy.pp

      Adding the module may take a few seconds. Once the command completes you can confirm that the module is loaded into the kernel by running the semodule command:

      • sudo semodule -l |grep rsyslog-haproxy

      You should receive output like the following:

      Output

      rsyslog-haproxy

      Once the module is loaded you can restart Rsyslog with the following command:

      • sudo systemctl restart rsyslog

      You have now defined, compiled, and loaded an SELinux policy that will allow HAProxy and Rsyslog to communicate over their shared socket.

      In the next step you will test that everything works by making an HTTP request to HAProxy and examining its new log file.

      Step 5 — Testing HAProxy Logging

      Now that you have configured HAProxy, Rsyslog, and optionally SELinux, you can test that logging to /var/log/haproxy.log is working.

      By default the haproxy package ships with a configuration file that creates an HTTP listener socket on port 5000. The configuration points to a non-existent backend server, so any request to the port will result in an HTTP 503 error.

      To check for a 503 error in your /var/log/haproxy.log file, first generate an HTTP request using curl like this:

      • curl -si http://127.0.0.1:5000

      You should receive output like the following:

      Output

      HTTP/1.0 503 Service Unavailable Cache-Control: no-cache Connection: close Content-Type: text/html <html><body><h1>503 Service Unavailable</h1> No server is available to handle this request. </body></html>

      Now examine /var/log/haproxy.log for any HTTP 503 responses using the grep command:

      • sudo grep -E ‘NOSRV.+503’ /var/log/haproxy.log

      Note: The NOSRV.+503 portion of the command is a regular expression. This tutorial on Using Grep & Regular Expressions to Search for Text Patterns in Linux
      goes into more depth on using grep and regular expressions.

      You should receive a line (or multiple lines) like the following:

      [secondary_label Output
      Sep 9 21:32:22 centos-s-1vcpu-1gb-nyc3-01 haproxy[4451]: 127.0.0.1:56024 [9/Sep/2020:21:32:22.098] main app/<NOSRV> 0/-1/-1/-1/0 503 212 - - SC-- 1/1/0/0/0 0/0 "GET / HTTP/1.1"
      

      This line corresponds to the curl request that you made, which means that Rsyslog and HAProxy are configured to use their shared socket correctly.

      Conclusion

      In this quickstart tutorial, you configured HAProxy to log to a Unix domain socket. You also set up Rsyslog to create and read from the socket so that the two programs can communicate with each other without opening up any TCP/IP ports on your system. Finally, you optionally compiled, packaged, and loaded an SELinux policy to allow Rsyslog and HAProxy shared access to their socket.



      Source link

      How To Install and Configure Mahara on Ubuntu 18.04


      The author selected the COVID-19 Relief Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      Mahara is an open-source ePortfolio and social networking system that bills itself as a “learner-centered personal learning environment.” Mahara is especially popular in academic institutions where it provides learners a platform to curate and share their knowledge and growth. In a remote learning environment, Mahara can help educators foster a digital classroom and organize a student’s progress. Unlike more a traditional Learning Management Systems (LMS), Mahara is more distributed and user-focused. This amount of user creativity contrasts other, more institutional systems.

      Mahara also has many non-student applications. You can use it to build a blog, a resume-builder, a file-repository, or a competency framework.

      In this guide, you will install Mahara and configure it to use a Postgres database as an authentication source. Upon completion, you will have administrative access to a server-based ePortfolio.

      Prerequisites

      Step 1 — Creating a Database and User for Mahara

      Your first step is to create a Postgres database and user for Mahara.

      From your server’s command line, switch to the postgres user:

      The -i switch provides an interactive shell, while sudo used with the -u switch allows you to switch users.

      Now create a Postgres user; make sure to replace mahara with your preferred username:

      Postgres will prompt you to Enter password for a new role:. role here refers to the new user you are trying to create. Provide a password of your choosing, and then reenter the password when prompted.

      Now create a database for your Mahara installation. Use the following command, replacing maharadb with a preferred name for your new database and mahara with the new user you just created:

      • createdb -O mahara -EUTF8 maharadb

      You can now exit from the postgres user:

      Note: It is recommended to use Postgres for your Mahara database, but if you decide to use MySQL, you’ll need to set up a new user and database for Mahara. To do so, log in to your MySQL root account using the following command:

      Provide your MySQL root password to gain access. Now create your Mahara database. Replace maharadb with another name:

      • create database maharadb character set UTF8;

      Next, create a new MySQL user for Mahara, set a password, and grant it access to your maharadb database. Remember to provide a strong password in place of password and replace mahara with your desired username:

      • grant all on maharadb .* to 'mahara '@'localhost' identified by 'password';

      You have now created a database for Mahara and created a role. Now you can install and configure Mahara.

      Step 2 — Downloading Mahara

      Now that you have a database created and configured for Mahara, let’s download Mahara itself. You can download a standard build from Mahara’s server, and you can find the latest Mahara build here.

      Once you have a .tar.gz link to the latest stable release, download it using the wget command. Make sure to replace /19.10/19.10.2/+download/mahara-19.10.2.tar.gz with the release you selected:

      • wget https://launchpad.net/mahara/19.10/19.10.2/+download/mahara-19.10.2.tar.gz

      This will download a compressed file labeled mahara-19.10.2.tar.gz. Extract the compressed file to create the Mahara directory structure:

      • tar xzvf mahara-19.10.2.tar.gz
      • ls

      The ls command checks the extraction. You will now see the new mahara-19.10.2 directory:

      Output

      mahara-19.10.2.tar.gz mahara-19.10.2

      Let’s copy Mahara to /var/www/mahara.your_domain. mahara.your_domain should match the directory you created during the Virtual Host configuration step in the Prerequisite section.

      Note: Mahara must install into an empty directory. If you have files here already, consider changing your DocumentRoot and using a new directory.

      Now copy the Mahara directory:

      • sudo cp -a mahara-19.10.2/. /var/www/mahara.your_domain/

      The -a switch ensures that the system copies the file permissions along with the files and folders. The . at the end of the source file ensures that everything in the source directory, including hidden files, gets copied to the destination directory.

      Mahara requires additional PHP extensions to function correctly.

      Run the following commands to install all the necessary dependencies:

      • sudo apt update
      • sudo apt install php-gd php-pgsql php-xmlrpc php-xml php-curl php-mbstring

      Type y for any prompts to finish the installation.

      You have installed Mahara on your server. Next, you will create the dataroot directory.

      Step 3 — Creating the Dataroot Directory

      Now that you have your Mahara code set up let’s create a dataroot directory. This is where Mahara will write uploaded files as well as some other files it needs to run. Therefore, the web server needs to be able to write to it.

      The dataroot directory should also be outside the directory where you have your Mahara code. You should avoid having it inside your public_html directory altogether.

      Let’s create the directory in /var/maharadata:

      • sudo mkdir /var/maharadata

      Update the ownership with chown:

      • sudo chown -R www-data:www-data /var/maharadata

      This allows the web server to write in the directory. Now we can finish configuring Mahara.

      Step 4 — Setting Up the Mahara Configuration File

      In this step you will make some final adjustments to Mahara’s config.php file. These adjustments will connect your database and encrypt your password.

      Switch to the Mahara code directory:

      • cd /var/www/mahara.your_domain/htdocs

      Create your config.php file by copying the config-dist.php file in the htdocs directory.

      Change directories and copy the file:

      • cp config-dist.php config.php

      Now open config.php using nano or your preferred text editor:

      Locate the following section in the file and make the required changes. Leave $cfg->dbtype as postgres unless you’re using MySQL, in which case change it to mysql. Change maharadb, mahara, and dbpassword to match the values you used in Step 1 for the database name, user, and password, respectively:

      ./htdocs/config.php

      ...
      $cfg->dbtype="postgres";
      $cfg->dbhost="localhost";
      $cfg->dbport   = null; // Change if you are using a non-standard port number for your database
      $cfg->dbname="maharadb";
      $cfg->dbuser="mahara";
      $cfg->dbpass="dbpassword";
      ...
      

      In the same file, locate the following section:

      /var/www/mahara/htdocs/config.php

      ...
      $cfg->dataroot="/path/to/uploaddir";
      ...
      

      Change it to point to Mahara’s dataroot directory as you set it in Step 3:

      /var/www/mahara/htdocs/config.php

      ...
      $cfg->dataroot="/var/maharadata";
      ...
      

      Finally, let’s update the passwordsaltmain with a random secret string. This encrypts stored user passwords. Locate and uncomment the following line:

      /var/www/mahara/htdocs/config.php

      ...
      // $cfg->passwordsaltmain = 'some long random string here with lots of characters';
      ...
      

      You can use the OpenSSL rand function to generate a random string to use as your secret salt string. Open a new terminal, connect to your server again, and run the following command to generate this string:

      The -base64 32 option ensures a Base64 encoded string that is 32 characters long. Update the value for passwordsaltmain to your_generated_salt:

      /var/www/mahara/htdocs/config.php

      ...
      $cfg->passwordsaltmain = 'your_generated_salt';
      ...
      

      Warning: Once set, you must not lose this string or you will need to reset all user passwords. It’s good practice to keep a secure backup of your config.php file

      Note: You may wish to set productionmode to false when using Mahara as a development or test site. Setting this to false will enable the on-screen display of warnings and error messages to aid in testing.

      Save and close the file.

      With Mahara configured, you are ready to serve Mahara using the Apache web server.

      Step 5 — Configuring Apache

      In the prerequisites, you configured a domain and pointed it to this server. You also installed Apache and set up HTTPS using Let’s Encrypt. Let’s now use Apache to serve Mahara.

      If your Virtual Host configuration file is named mahara.your_domain.conf Let’s Encrypt created a new configuration file called mahara.your_domain-le-ssl.conf that handles HTTPS requests for your domain.

      Open that file. Be sure to replace mahara.your_domain with the actual name of your file:

      • sudo nano /etc/apache2/sites-available/mahara.your_domain-le-ssl.conf

      The file will look similar to this:

      /etc/apache2/sites-available/your_domain-le-ssl.conf

      ...
      <IfModule mod_ssl.c>
      <VirtualHost *:443>
              ServerAdmin webmaster@localhost
              ServerName mahara.your_domain
              DocumentRoot /var/www/mahara.your_domain
              ErrorLog ${APACHE_LOG_DIR}/error.log
              CustomLog ${APACHE_LOG_DIR}/access.log combined
      
      SSLCertificateFile /etc/letsencrypt/live/mahara.your_domain/fullchain.pem
      SSLCertificateKeyFile /etc/letsencrypt/live/mahara.your_domain/privkey.pem
      Include /etc/letsencrypt/options-ssl-apache.conf
      </VirtualHost>
      </IfModule>
      ...
      

      The ServerName directive defines the base domain that should match for this virtual host definition. This should also be the domain name you chose to secure with an SSL certificate in the Prerequisites section.

      Note: Your Apache configuration should contain no ServerAliases. Mahara expects to be accessed through one url. If you use a server alias, you’ll experience issues like having to log in twice and breaking Single Sign On (SSO) features.

      However, if you do need an alias for some reason, you can set up a separate second VirtualHost directive in addition to the one above.

      Make the following additions to the file:

      /etc/apache2/sites-available/your_domain-le-ssl.conf

      ...
      <IfModule mod_ssl.c>
      <VirtualHost *:443>
              ServerAdmin webmaster@localhost
              ServerName mahara.your_domain
              DocumentRoot /var/www/mahara.your_domain/htdocs
      
              <Directory />
                  Options FollowSymLinks
                  AllowOverride None
              </Directory>
      
              <Directory /var/www/your_domain/htdocs>
                  Options Indexes FollowSymLinks MultiViews
                  AllowOverride None
                  Order allow,deny
                  allow from all
              </Directory>
      
              ErrorLog ${APACHE_LOG_DIR}/error.log
              CustomLog ${APACHE_LOG_DIR}/access.log combined
      
      SSLCertificateFile /etc/letsencrypt/live/mahara.your_domain/fullchain.pem
      SSLCertificateKeyFile /etc/letsencrypt/live/mahara.your_domain/privkey.pem
      Include /etc/letsencrypt/options-ssl-apache.conf
      </VirtualHost>
      </IfModule>
      ...
      

      First, you update the DocumentRoot to include /htdocs. Then you add two new blocks.

      The <Directory /> block refers to the filesystem root. It specifies directives applying to all files and directories anywhere on the server. Specifying directives for this block allows us to protect your server from intrusions by placing default directives such as AllowOverride None.

      The <Directory /var/www/mahara.your_domain/htdocs> block refers to the document root for Mahara. Directives declared here override ones declared on the <Directory /> block. These directives are the fundamental requirements for an Apache configuration to serve Mahara.

      Save and close the file.

      You are now ready to configure your PHP service.

      Step 6 — Adjusting PHP Settings

      Our final step is to update Apache’s php.ini file. This will change our logging verbosity and resize maximum upload and POST sizes.

      Open the file:

      • sudo nano /etc/php/7.2/apache2/php.ini

      This is a large file. Let’s go through the updates one by one.

      Find the log_errors line and make sure it matches the highlighted code:

      /etc/php/7.2/apache2/php.ini

      . . .
      log_errors = On
      . . .
      

      Setting log_errors to On will enable PHP to log errors encountered while running Mahara to aid in debugging.

      Now find the line beginning upload_max_filesize = 2M. Replace 2M with 50M:

      7.2/apache2/php.ini’>/etc/php/7.2/apache2/php.ini

      . . .
      upload_max_filesize = 50M
      . . .
      

      This will increase the max upload file size to 50 megabytes.

      Now find the line beginning post_max_size = 8M. Replace 8M with 100M:

      7.2/apache2/php.ini’>/etc/php/7.2/apache2/php.ini

      . . .
      post_max_size = 100M
      . . .
      

      upload_max_filesize accounts for the maximum size allowed for files posted, while post_max_size is the maximum size allowed for all POST body data. So you’ll always want to have this second number higher. These settings will enable Mahara to accept file uploads at the set maximums.

      Now move to the end of the file and add the following directives:

      /etc/php/7.2/apache2/php.ini

      ...
      register_globals = Off
      magic_quotes_runtime = Off
      magic_quotes_sybase = Off
      magic_quotes_gpc = Off
      allow_call_time_pass_reference = Off
      

      register_globals = Off disables register_globals. Enabling it has security implications as highlighted on PHP’s Manual.

      Setting magic_quotes_runtime to Off stops PHP from automatically escaping quotes with a backslash from any functions coming in from an external source (POST/GET). magic_quotes_runtime, magic_quotes_sybase, and magic_quotes_gpc are deprecated.

      allow_call_time_pass_reference is also deprecated.

      Save and close the file.

      Now restart Apache:

      • sudo systemctl restart apache2

      This completes your server setup. You are now ready to run the Mahara installer and enter your ePortfolio through a web browser.

      Step 7 — Running the Mahara Installer

      With Apache and PHP properly configured, let’s proceed to finish up Mahara’s installation through its web-based installer.

      In your browser, navigate to your server’s domain name. A screen will appear displaying Mahara’s licensing information and a button to continue installation.

      Mahara Install Screen

      Click the Install Mahara button and wait until the installer finishes performing all installations. Once done, scroll down. You will see a section that says Successfully installed Mahara. Continue. Click on Continue to proceed.

      Mahara will prompt you to enter a new password and a primary email address. Go ahead and submit the form.

      Mahara Welcome Screen

      You are ready to start using Mahara. But before you start exploring your new ePortfolio, you might want to set up a few final features.

      Set up Email

      For production settings, make sure that Mahara can send out emails. This is useful for sending out notifications such as confirmation emails after users register on the site. You can specify an outgoing SMTP server with admin settings. Click on the drop-down menu on the upper-right and choose Configure Site -> Site options -> Email.

      Set up a Cron Job

      Lastly, consider setting up a cron job to hit htdocs/lib/cron.php every minute. Without setting this up, you will find that RSS feeds will not update and some email notifications won’t get sent out. Go ahead and enter the following command. You’ll get an option to select the editor of your choice. In this example, we’re proceeding with the nano editor:

      Add the following line at the bottom of the file replacing mahara.your_domain with the name of the directory where you installed Mahara on Step 2:

      * * * * * php /var/www/mahara.your_domain/htdocs/lib/cron.php
      

      With your email and cron job configured, you are now ready to use Mahara.

      Conclusion

      Mahara is a powerful and popular platform. It is a great resource for teacher and learners, particularly within remote-learning environments. Mahara is also popular outside of education, where users create blogs and resume builders.

      Users can also choose from numerous themes while admins can explore a large library of plugins.

      After familiarizing yourself with the user interface, consider following the Next Steps article on Mahara’s website for more ideas.



      Source link

      How To Install and Configure Neo4j on Ubuntu 20.04


      Introduction

      Neo4j is a graph database that records relationships between data nodes, whereas traditional relational databases use rows and columns to store and structure data. Since each node stores references to all the other nodes that it is connected to, Neo4j can encode and query complex relationships with minimal overhead.

      Prerequisites

      To follow this tutorial, you will need the following:

      Step 1 — Installing Neo4j

      The official Ubuntu package repositories do not contain a copy of the Neo4j database engine. To install the upstream supported package from Neo4j, we’ll add a new package source pointing to the Neo4j repository, add the GPG key from Neo4j to ensure the downloads are valid, and then install the package.

      To get started, update your existing list of packages:

      Next, install a few prerequisite packages, which will let apt install packages using HTTPS connections. Your system may already have these packages installed by default, but it is safe to run the following command anyways.

      • sudo apt install apt-transport-https ca-certificates curl software-properties-common

      Now add the GPG key for the official Neo4j package repository to your system. This key will ensure that you can trust Neo4j packages that are installed from the upstream repository. Run the following command to install the key:

      • curl -fsSL https://debian.neo4j.com/neotechnology.gpg.key | sudo apt-key add -

      Next, add the Neo4j 4.1 repository to your system’s APT sources:

      • sudo add-apt-repository "deb https://debian.neo4j.com stable 4.1"

      The next step is to install the Neo4j package, and all of its dependencies. This step will download and install a compatible Java package, so you can enter Y when the apt command prompts you to install all the dependencies:

      Once the installation process is complete, Neo4j should be running. However, it is not set to start on a reboot of your system. So the last setup step is to enable it as a service:

      • sudo systemctl enable neo4j.service

      After completing all of these steps, examine Neo4j’s status using the systemctl command:

      • sudo systemctl status neo4j.service

      You should have output that is similar to the following:

      Output

      ● neo4j.service - Neo4j Graph Database Loaded: loaded (/lib/systemd/system/neo4j.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2020-08-07 01:43:00 UTC; 6min ago Main PID: 21915 (java) Tasks: 45 (limit: 1137) Memory: 259.3M CGroup: /system.slice/neo4j.service . . .

      There will be other verbose lines of output, but the important things to note are the highlighted enabled and running lines. Once you have Neo4j installed and running, you can move on to the next set of steps, which will guide you through connecting to Neo4j, configuring credentials, and inserting nodes into the database.

      Step 2 — Connecting to and Configuring Neo4j

      Now that you have Neo4j installed and configured to run after any reboot, you can test connecting to the database, and configure administrator credentials.

      To interact with Neo4j on the command line, use the cypher-shell utility. Invoke the utility like this:

      When you first invoke the shell, you will login using the default administrative neo4j user and neo4j password combination. Once you are authenticated, Neo4j will prompt you to change the administrator password:

      cypher-shell prompt

      username: neo4j password: ***** Password change required new password: ******************** Connected to Neo4j 4.1.0 at neo4j://localhost:7687 as user neo4j. Type :help for a list of available commands or :exit to exit the shell. Note that Cypher queries must end with a semicolon. neo4j@neo4j>

      In this example, the highlighted ******************** is the masked version of the new password. Choose your own strong and memorable password and be sure to record it somewhere safe. Once you set the password you will be connected to the interactive neo4j@neo4j> prompt where you can interact with Neo4j databases by inserting and querying nodes.

      Note: The Community Edition of Neo4j supports running a single database at a time. Additionally, the Community version does not include the capability to assign roles and permissions to users so those steps are not included in this tutorial. For more information about various features that are supported by the Community Edition of Neo4j, consult the Neo4j Documentation here.

      Now that you have set an administrator password and tested connecting to Neo4j, exit from the cypher-shell prompt by typing :exit:

      Next you can optionally configure Neo4j to accept remote connections.

      Step 3 (Optional) — Configuring Neo4j for Remote Access

      If you would like to incorporate Neo4j into a larger application or environment that uses multiple servers, then you will need to configure it to accept connections from other systems. In this step you will configure Neo4j to allow remote connections, and you will also add firewall rules to restrict which systems can connect to your Neo4j server.

      By default Neo4j is configured to accept connections from localhost only (127.0.0.1 is the IP address for localhost). This configuration ensures that your Neo4j server is not exposed to the public Internet, and that only users with access to the local system can interact with Neo4j.

      To change the network socket that Neo4j uses from localhost to one that other systems can use, you will need to edit the /etc/neo4j/neo4j.conf file. Open the configuration file in your preferred editor and find the dbms.default_listen_address setting. The following example uses nano to edit the file:

      • sudo nano /etc/neo4j/neo4j.conf

      Locate the commented out #dbms.default_listen_address=0.0.0.0 line and uncomment it by removing the leading # comment character.

      /etc/neo4j/neo4j.conf

      . . .
      #*****************************************************************
      # Network connector configuration
      #*****************************************************************
      
      # With default configuration Neo4j only accepts local connections.
      # To accept non-local connections, uncomment this line:
      dbms.default_listen_address=0.0.0.0
      . . .
      

      By default, the value 0.0.0.0 will bind Neo4j to all available IPv4 interfaces on your system, including localhost. If you would like to limit Neo4j to a particular IP address, for example a private network IP that your servers use for a datapath, specify the IP address that is assigned to your server’s private network interface here.

      You can also configure Neo4j to use IPv6 interfaces. As with IPv4, you can set the default_listen_address value to a specific IPv6 address that you will use to communicate with Neo4j. If you want to limit Neo4j to only use the local IPv6 address for your server, specify ::1, which corresponds to localhost using IPv6 notation.

      When you are finished configuring the default IP address that Neo4j will use for connections, save and close neo4j.conf. If you’re using nano, you can do so by pressing CTRL+X, followed by Y and then ENTER.

      Note: If you configure Neo4j with an IPv6 address, you will not be able to connect to Neo4j with cypher-shell using the IPv6 address directly. Instead, you will need to either configure a DNS name that resolves to the IPv6 address, or add an entry in the remote system’s /etc/hosts file that maps the address to a name. You will then be able to use the DNS or hosts file name to connect to Neo4j using IPv6 from your remote system.

      For example, a Neo4j server with an IPv6 address like 2001:db8::1 would require the remote connecting system to have an /etc/hosts entry like the following, substituting a name in place of the highlighted your_hostname:

      /etc/hosts

      . . .
      2001:db8::1 your_hostname
      

      You would then connect to the server from the remote system using the name that you specified like this:

      • cypher-shell -a 'neo4j://your_hostname:7687'

      If you restrict Neo4j to use the IPv6 localhost address of ::1, then you can connect to it locally on the Neo4j server itself using the preconfigured ip6-localhost name from your /etc/hosts file like this:

      • cypher-shell -a 'neo4j://ip6-localhost:7687'

      Once you invoke cypher-shell with the connection URI, you will be prompted for your username and password as usual.

      Now that you have configured Neo4j to allow remote connections, it is important to limit remote access so that only trusted systems can connect to it. To restrict remote access to Neo4j, you can use Ubuntu’s default UFW firewall. If you followed the prerequisite Initial Server Setup with Ubuntu 20.04 tutorial then UFW is already installed and ready for use on your server.

      Neo4j creates two network sockets in a default installation, one on port 7474 for the built-in HTTP interface, and the main bolt protocol on port 7687. Neo4j recommends not using the HTTP port in production, so we’ll create firewall rules for port 7687 only.

      To configure the firewall to allow a trusted remote host access to the bolt interface using IPv4, type the following command:

      UFW IPv4 Single Host Example

      • sudo ufw allow from 203.0.113.1 to any port 7687 proto tcp

      Substitute the IP address of the trusted remote system that you will use to access Neo4j in place of the highlighted 203.0.113.1 value.

      If you want to allow an entire network range access, like a private management or datapath network, use a rule like this one:

      UFW IPv4 Network Example

      • sudo ufw allow from 192.0.2.0/24 to any port 7687 proto tcp

      Again, substitute the network that you would like to have access to Neo4j in place of the highlighted 192.0.2.0/24 network.

      If you would like to allow hosts to access Neo4j remotely using IPv6, add a rule like the following:

      UFW IPv6 Single Host Example

      • sudo ufw allow from 2001:DB8::1/128 to any port 7687 proto tcp

      Substitute your trusted system’s IPv6 address in place of the highlighted 2001:DB8::1/128 address.

      As with IPv4, you can also allow a range of IPv6 addresses access to your Neo4j server. To do so create a UFW rule like the following:

      UFW IPv6 Single Host Example

      • sudo ufw allow from 2001:DB8::/32 to any port 7687 proto tcp

      Again substitute in your trusted network range in place of the highlighted 2001:DB8::/32 network range.

      Once you have created the appropriate UFW rule or rules for your network configuration and trusted hosts or networks, enable UFW to make the rules take effect:

      You can examine the currently loaded UFW rules using the ufw status command. Run it to ensure that the addresses or networks that you specified can access Neo4j on port 7687:

      You should have output that is similar to the following:

      Output

      Status: active To Action From -- ------ ---- 22/tcp ALLOW Anywhere 22/tcp (v6) ALLOW Anywhere (v6) 7687/tcp ALLOW 203.0.113.1

      You now have a Neo4j server that is configured to allow access on port 7687 to a trusted remote server or network. In the next section of this tutorial you will learn about adding nodes to the database, and how to define relationships between them.

      Step 4 — Using Neo4j

      To start using Neo4j, let’s add some example nodes and then define relationships between them. Connect to Neo4j using cypher-shell.

      Note: If you configured Neo4j to allow remote access in [Step 3 (Optional) — Configuring Neo4j for Remote Access](step-3-optional-configuring-neo4j-for-remote-access], connect using a URI that corresponds to the address of your Neo4j server. For example if your Neo4j server’s IP is 203.0.113.1, then connect to it like this from your remote system:

      • cypher-shell -a 'neo4j://203.0.113.1:7687'

      You will be prompted for your username and password as usual.

      If you are using IPv6, ensure that you have an /etc/hosts entry with a name as described in Step 3. Then connect to your Neo4j server from your remote system with a cypher-shell command like this:

      • cypher-shell -a 'neo4j://your_hostname:7687'

      Again, ensure that the highlighted your_hostname maps to your Neo4j server’s IPv6 address in your remote system’s /etc/hosts file.

      Once you have logged into Neo4j with your username and password, you can query and add nodes and relationships to the database.

      To get started, add a Great White shark node to Neo4j. The following command will create a node of type Shark, with a name Great White.

      • CREATE (:Shark {name: 'Great White'});

      After each command you will receive output that is similar to the following:

      Output

      0 rows available after 3 ms, consumed after another 0 ms Added 1 nodes, Set 1 properties, Added 1 labels

      Note: A full explanation of each of the following cypher queries is beyond the scope of this tutorial. For details about the syntax of the cypher query language, refer to the The Neo4j Cypher Manual .

      Next, add some more sharks, and relate them using a relationship called FRIEND. Neo4j allows you to relate nodes with arbitrarily named relationships, so FRIEND can be whatever label for a relationship that you would like to use.

      In the following example we’ll add three sharks, and link them together using a relationship called FRIEND:

      • CREATE
      • (:Shark {name: 'Hammerhead'})-[:FRIEND]->
      • (:Shark {name: 'Sammy'})-[:FRIEND]->
      • (:Shark {name: 'Megalodon'});

      You should receive output that indicates the three new sharks were added to the database:

      Output

      . . . Added 3 nodes, Created 2 relationships, Set 3 properties, Added 3 labels

      Neo4j allows you to relate nodes using arbitrary names for relationships, so in addition to their existing FRIEND relation, Sammy and Megalodon can also be related using a taxonomic rank.

      Sammy and Megalodon share a common order of Lamniformes. Since relationships can have properties just like nodes, we’ll create an ORDER relationship with a name property that is set to Lamniformes to help describe one of Sammy and Megalodon’s relationships:

      • MATCH (a:Shark),(b:Shark)
      • WHERE a.name="Sammy" AND b.name="Megalodon"
      • CREATE (a)-[r:ORDER { name: 'Lamniformes' }]->(b)
      • RETURN type(r), r.name;

      After adding that relationship, you should have output like the following:

      Output

      +-------------------------+ | type(r) | r.name | +-------------------------+ | "ORDER" | "Lamniformes" | +-------------------------+ 1 row available after 2 ms, consumed after another 7 ms Created 1 relationships, Set 1 properties

      Next, add a SUPERORDER relationship between Sammy and Hammerhead based on their taxonomic superorder, which is Selachimorpha. Again, the relationship is given a name property, which is set to Selachimorpha:

      • MATCH (a:Shark),(b:Shark)
      • WHERE a.name="Sammy" AND b.name="Hammerhead"
      • CREATE (a)-[r:SUPERORDER { name: 'Selachimorpha'}]->(b)
      • RETURN type(r), r.name;

      Again you will receive output that indicates the type of the relationship, along with the name that was added to describe the relation:

      Output

      +--------------------------------+ | type(r) | r.name | +--------------------------------+ | "SUPERORDER" | "Selachimorpha" | +--------------------------------+ 1 row available after 2 ms, consumed after another 8 ms Created 1 relationships, Set 1 properties

      Finally, with all these nodes and relationships defined and stored in Neo4j, examine the data using the following query:

      • MATCH (a)-[r]->(b)
      • RETURN a.name,r,b.name
      • ORDER BY r;

      You should receive output like the following:

      Output

      +---------------------------------------------------------------------+ | a.name | r | b.name | +---------------------------------------------------------------------+ | "Hammerhead" | [:FRIEND] | "Sammy" | | "Sammy" | [:FRIEND] | "Megalodon" | | "Sammy" | [:ORDER {name: "Lamniformes"}] | "Megalodon" | | "Sammy" | [:SUPERORDER {name: "Selachimorpha"}] | "Hammerhead" | +---------------------------------------------------------------------+ 4 rows available after 72 ms, consumed after another 1 ms

      The output includes the FRIEND relationships that were defined between Hammerhead, Sammy, and Megalodon, as well as the ORDER and SUPERORDER taxonomic relationships.

      When you are finished adding and exploring nodes and relationships to your Neo4j database, type the :exit command to leave the cypher-shell.

      Conclusion

      You have now installed, configured, and added data to Neo4j on your server. You also optionally configured Neo4j to accept connections from remote systems and secured it using UFW.

      If you want to learn more about using Neo4j and the cypher query language, consult the official
      Neo4j Documentation.



      Source link