One place for hosting & domains


      How To Set Up a JupyterLab Environment on Ubuntu 18.04

      The author selected the United Nations Foundation to receive a donation as part of the Write for DOnations program.


      JupyterLab is a highly feature-rich UI that makes it easy for users, particularly in the fields of Data Science and AI, to perform their tasks. The JupyterLab environments provide a productivity-focused redesign of Jupyter Notebook. It introduces tools such as a built-in HTML viewer and CSV viewer along with features that unify several discrete features of Jupyter Notebooks onto the same screen.

      In this tutorial, you’ll install and set up JupyterLab on your Ubuntu 18.04 server. You’ll also be configuring your server to be able to connect to the JupyterLab instance remotely from any web browser, securely, using a domain name.


      In order to complete this tutorial, you’ll need:

      • An Ubuntu 18.04 server with a non-root user account with sudo privileges using this Initial Server Setup Guide.
      • An installation of the Python Anaconda Distribution on your server. You can use the How To Install the Anaconda Python Distribution on Ubuntu 18.04 tutorial.
      • A registered domain name or sub-domain where you’ve access to edit DNS records. This tutorial will use your_domain throughout. You can purchase domains on Namecheap, get a free domain at Freenom, or register a new domain with any registrar of your choice.
      • The following DNS records set up for your domain:
        • An A record with your_domain pointing to your server’s public IP address.
        • An A record with www.your_domain pointing to your server’s public IP address.
          This How to Create, Edit, and Delete DNS Records documentation can help you in setting up these records.

      Step 1 — Setting Up Your Password

      In this step you’ll set up a password on your JupyterLab installation. It is important to have a password in place since your instance will be publicly accessible.

      First, make sure your Anaconda environment is activated. As per the prerequisite tutorial the environment is called base.

      To activate the environment, use the following command:

      Your prompt will change in the terminal to reflect the default Anaconda environment base:

      All future commands in this tutorial will be run within the base environment.

      With your Anaconda environment activated, you’re ready to set up a password for JupyterLab on your server.

      First, let’s generate a configuration file for Jupyter:

      • jupyter notebook --generate-config

      You’ll receive the following output:


      Writing default config to: /home/sammy/.jupyter/

      Both JupyterLab and Jupyter Notebook share the same configuration file.

      Now, use the following command to set a password for accessing your JupyterLab instance remotely:

      • jupyter notebook password

      Jupyter will prompt you to provide a password of your choice:


      Enter password: Verify password: [NotebookPasswordApp] Wrote hashed password to /home/sammy/.jupyter/jupyter_notebook_config.json

      Jupyter stores the password in a hashed format at /home/sammy/.jupyter/jupyter_notebook_config.json. You’ll need this hashed value in the future.

      Finally, use the cat command on the file generated by the previous command to view the hashed password:

      • cat /home/sammy/.jupyter/jupyter_notebook_config.json

      You’ll receive an output similar to the following:


        "NotebookApp": {
          "password": "sha1:your_hashed_password"

      Copy the value in the password key of the JSON and store it temporarily.

      You’ve set up a password for your JupyterLab instance. In the next step you’ll create a Let’s Encrypt certificate for your server.

      Step 2 — Configuring Let’s Encrypt

      In this step, you’ll create a Let’s Encrypt certificate for your domain. This will secure your data when you access your JupyterLab environment from your browser.

      First, you’ll install Certbot to your server. Begin by adding its repository to the apt sources:

      • sudo add-apt-repository ppa:certbot/certbot

      On executing the command, you’ll be asked to press ENTER to complete adding the PPA:


      This is the PPA for packages prepared by Debian Let's Encrypt Team and backported for Ubuntu. Note: Packages are only provided for currently supported Ubuntu releases. More info: Press [ENTER] to continue or Ctrl-c to cancel adding it.

      Press ENTER to continue adding the PPA.

      Once the command has finished executing, refresh the apt sources using the apt update command:

      Next, you’ll install Certbot:

      Before you can start running Certbot to generate certificates for your instance, you’ll allow access on port :80 and port :443 of your server, so that Certbot can use these ports to verify your domain name. Port :80 is checked for http requests to the server while port :443 is used for https requests. Certbot shall be making an http request first and then after obtaining the certficates for your server, it will make an https request, which will be proxied through port :443 to the process listening at :80 port. This will verify the success of your certificate installation.

      First, allow access to port :80:

      You will receive the following output:


      Rule added Rule added (v6)

      Next, allow access to port :443:


      Rule added Rule added (v6)

      Finally, run Certbot to generate certificates for your instance using the following command:

      • sudo certbot certonly --standalone

      The standalone flag directs certbot to run a temporary server for the duration of the verfication process.

      It will prompt you for your email:


      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): your_email

      Enter a working email and press ENTER.

      Next, it will ask you to review and agree to the Terms of Service for Certbot and Let’s Encrypt. Review the terms, type A if you accept, and press ENTER:


      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at You must agree in order to register with the ACME server at - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (A)gree/(C)ancel: A

      It will now prompt you to share your email with the Electronic Frontier Foundation. Type your answer and press ENTER:


      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: Y/N

      Finally, you’ll be asked to enter your domain name. Type in your domain name without any protocol specification:


      Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): your_domain Obtaining a new certificate Performing the following challenges: http-01 challenge for your_domain Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem Your cert will expire on 2020-09-28. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: Donating to EFF:

      Certbot will perform domain verification and generate certificates and keys for your domain and store them at /etc/letsencrypt/live/your_domain.

      Now that you have set up your Let’s Encrypt certificate, you’ll update your JupyterLab configuration file.

      Step 3 — Configuring JupyterLab

      In this step, you will edit the JupyterLab configuration to make sure it uses the Let’s Encrypt certificate you generated in Step 2. You will also make it accessible using the password you set up in Step 1.

      First, you need to edit the JupyterLab configuration file at /home/sammy/.jupyter/

      • nano /home/sammy/.jupyter/

      Now, navigate to the line defining the value for c.NotebookApp.certfile and update it as follows:


      ## The full path to an SSL/TLS certificate file.

      Next, find the c.NotebookApp.keyfile variable and set it as shown:


      ## The full path to a private key file for usage with SSL/TLS.

      c.NotebookApp.certfile and c.NotebookApp.keyfile refer to the SSL Certificate, which will be served when you try to access your server remotely using the https protocol.

      Next, navigate to the line defining the c.NotebookApp.ip variable and update as follows:


      ## The IP address the notebook server will listen on.
      c.NotebookApp.ip = '*'

      c.NotebookApp.ip defines the IPs that can access JupyterLab running your server. You set it to the * wildcard to allow access from any computer you need to access JupyterLab on.

      Next, find the c.NotebookApp.open_browser configuration and update it as follows:


      ## Whether to open in a browser after starting. The specific browser used is
      #  platform dependent and determined by the python standard library `webbrowser`
      #  module, unless it is overridden using the --browser (NotebookApp.browser)
      #  configuration option.
      c.NotebookApp.open_browser = False

      By default, JupyterLab attempts to automatically initiate a browser session when it starts running. Since we do not have a browser on the remote server, it is necessary to turn this off to avoid errors.

      Next, navigate down to the c.NotebookApp.password variable and change to the following:


      ## Hashed password to use for web authentication.
      #  To generate, type in a python/IPython shell:
      #    from notebook.auth import passwd; passwd()
      #  The string should be of the form type:salt:hashed-password.
      c.NotebookApp.password = 'your_hashed_password'

      JupyterLab will use this hashed password configuration to check the password you enter for access in your browser.

      Finally, navigate further through the file and update the entry of the c.NotebookApp.port:


      ## The port the notebook server will listen on.
      c.NotebookApp.port = 9000

      c.NotebookApp.port sets a fixed port for accessing your JupyterLab runtime. This way, you can allow access for only one port from the ufw firewall.

      Once you’re done, save and exit the file.

      Finally, allow traffic on the 9000 port:

      You’ll receive the following output:


      Rule added Rule added (v6)

      Now that you’ve set all your configuration, you’ll run JupyterLab.

      Step 4 — Running JupyterLab

      In this step, you’ll perform a test run of the JupyterLab instance.

      First, change your current working directory to the user’s home directory:

      Now, modify the access permissions of the certificate files to allow JupyterLab to access them. Change the permissions of the /etc/letsencrypt folder to the following:

      • sudo chmod 750 -R /etc/letsencrypt
      • sudo chown sammy:sammy -R /etc/letsencrypt

      Then, invoke your JupyterLab instance to start using the following command:

      This command accepts several configuration parameters. However, since we have already made these changes in the configuration file, we do not need to provide them here explicitly. You can provide them as arguments to this command to override the values in the configuration file.

      You can now navigate to https://your_domain:9000 to check you receive JupyterLab’s login screen.

      If you log in with the password you set up for JupyterLab in Step 2, you’ll be presented with the JupyterLab interface.

      JupyterLab interface after login

      Finally, press CTRL+C twice to stop the JupyterLab server.

      In the next step, you’ll set up a system service so that the JupyterLab server can be run in the background continuously.

      Step 6 — Setting Up a systemd Service

      In this step, you will create a systemd service that allows JupyterLab to keep running even when the terminal window is exited. You can read more about systemd services and units in this guide on systemd essentials.

      First, you’ll have to create a .service file, using the following command:

      • sudo nano /etc/systemd/system/jupyterlab.service

      Add the following content to the /etc/systemd/system/jupyterlab.service file:


      Description=Jupyter Lab Server
      ExecStart=/home/sammy/anaconda3/bin/jupyter-lab --config=/home/sammy/.jupyter/

      Save and exit the editor once you’re done.

      The service file automatically registers itself in the system as a daemon. However, it is not running by default.

      Use the systemctl command to start the service:

      • sudo systemctl start jupyterlab

      This starts the JupyterLab server in the background. You can check if the server has started by using the following command:

      • sudo systemctl status jupyterlab

      You’ll receive the following output:


      ● jupyterlab.service - Jupyter Lab Server Loaded: loaded (/etc/systemd/system/jupyterlab.service; disabled; vendor preset: enabled) Active: active (running) since Sun 2020-04-26 20:58:29 UTC; 5s ago Main PID: 5654 (jupyter-lab) Tasks: 1 (limit: 1152) CGroup: /system.slice/jupyterlab.service └─5654 /home/sammy/anaconda3/bin/python3.7 /home/sammy/anaconda3/bin/jupyter-lab --config=/home/

      Press Q to exit the service status output.

      You can now head to https://your_domain:9000 in any browser of your choice, provide the password you set up in Step 2, and access the JupyterLab environment running on your server.

      Step 7 — Configuring Renewal of Your Let’s Encrypt Certificate

      In this final step, you will configure your SSL certificates provided by Let’s Encrypt to automatically renew when they expire every 90 days and then restart the server to load the new certificates.

      While Certbot takes care to renew the certificates for your installation, it does not automatically restart the server. To configure the server to restart with new certificates, you will have to provide a renew_hook to the Certbot configuration for your server.

      You’ll need to edit the /etc/letsencrypt/renewal/your_domain.conf file and add a renew_hook to the end of the configuration file.

      First, use the following command to open the /etc/letsencrypt/renewal/your_domain.conf file in an editor:

      • sudo nano /etc/letsencrypt/renewal/your_domain.conf

      Then, at the bottom of this file, add the following line:


      renew_hook = systemctl reload jupyterlab

      Save and exit the file.

      Finally, run a dry-run of the renewal process to verify that your configuration file is valid:

      • sudo certbot renew --dry-run

      If the command runs without any error, your Certbot renewal has been set up successfully and will automatically renew and restart your server when the certificate is near the date of expiry.


      In this article, you set up a JupyterLab environment on your server and made it accessible remotely. Now you can access your machine learning or data science projects from any browser and rest assured that all exchanges are happening with SSL encryption in place. Along with that, your environment has all the benefits of cloud-based servers.

      Source link

      How To Install Django and Set Up a Development Environment on Ubuntu 20.04


      Django is a free and open-source web framework written in Python with its core principles being scalability, re-usability and rapid development. It is also known for its framework-level consistency and loose coupling, allowing for individual components to be independent of one another.

      In this tutorial, we will set up a Django environment for development purposes on an Ubuntu 20.04 server. For a live website, you will have additional considerations, including connecting to a database, setting up a domain name, and adding layers of security. We have a variety of tutorials on Django that can help support you as you build under our Django tag.


      In order to complete this tutorial, you will need:

      Step 1 — Installing Django

      There are several ways to install Django, the Python package manager pip within a virtual environment.

      While in the server’s home directory, we’ll create the directory that will contain our Django application. Run the following command to create a directory called django-apps, or another name of your choice. Then navigate to the directory.

      • mkdir django-apps
      • cd django-apps

      While inside the django-apps directory, create your virtual environment. We’ll call it the generic env, but you should use a name that is meaningful for you and your project.

      Now, activate the virtual environment with the following command:

      You’ll know it’s activated once the prefix is changed to (env), which will look similar to the following, depending on what directory you are in:

      Within the environment, install the Django package using pip. Installing Django allows us to create and run Django applications.

      Once installed, verify your Django installation by running a version check:

      This, or something similar, will be the resulting output:



      With Django installed on your server, we can move on to creating a test project to make sure everything is working correctly. We’ll be creating a skeleton web application.

      Step 2 — Adjusting Firewall Settings

      If you followed our initial server setup tutorial or have a firewall running on your server, we’ll need to open the port we’ll be using in our server’s firewall. For the UFW firewall, you can open the port with the following command:

      If you’re using DigitalOcean Firewalls, you can select HTTP from the inbound rules. You can read more about DigitalOcean Firewalls and creating rules for them by modifying the inbound rules.

      Step 3 — Starting the Project

      We now can generate an application using django-admin, a command line utility for administration tasks in Python. Then we can use the startproject command to create the project directory structure for our test website.

      While in the django-apps directory, run the following command:

      • django-admin startproject testsite

      Note: Running the django-admin startproject <projectname> command will name both project directory and project package the <projectname> and create the project in the directory in which the command was run. If the optional <destination> parameter is provided, Django will use the provided destination directory as the project directory, and create and the project package within it.

      Now we can look to see what project files were just created. Navigate to the testsite directory then list the contents of that directory to see what files were created:

      Output testsite

      You will notice output that shows this directory contains a file named and a folder named testsite. The file is similar to django-admin and puts the project’s package on sys.path. This also sets the DJANGO_SETTINGS_MODULE environment variable to point to your project’s file.

      You can view the script in your terminal by running the less command like so:

      When you’re finished reading the script, press q, to quit viewing the file.

      Now navigate to the testsite directory to view the other files that were created:

      Then run the following command to list the contents of the directory:

      You will see four files:


      Let’s go over what each of these files are:

      • acts as the entry point for your Python project.
      • contains the configuration for the optional deployment to the Asynchronous Server Gateway Interface or ASGI, which provides a standard for apps that are either synchronous and asynchronous, and is considered to be a successor of WSGI (see below).
      • describes the configuration of your Django installation and lets Django know which settings are available.
      • contains a urlpatterns list, that routes and maps URLs to their views.
      • contains the configuration for the Web Server Gateway Interface or WSGI, which provides a standard for synchronous Python apps.

      Note: Although default files are generated, you still have the ability to tweak the or files at any time to fit your deployment needs.

      Step 4 — Configuring Django

      Now we can start the server and view the website on a designated host and port by running the runserver command.

      We’ll need to add your server ip address to the list of ALLOWED_HOSTS in the file located in ~/test_django_app/testsite/testsite/.

      As stated in the Django docs, the ALLOWED_HOSTS variable contains “a list of strings representing the host/domain names that this Django site can serve. This is a security measure to prevent HTTP Host header attacks, which are possible even under many seemingly-safe web server configurations.”

      You can use your favorite text editor to add your IP address. For example, if you’re using nano, run the following command:

      • nano ~/django-apps/testsite/testsite/

      Once you run the command, you’ll want to navigate to the Allowed Hosts Section of the document and add your server’s IP address inside the square brackets within single or double quotes.

      Django settings for testsite project.
      Generated by 'django-admin startproject' using Django 2.0.
      # SECURITY WARNING: don't run with debug turned on in production!
      DEBUG = True
      # Edit the line below with your server IP address
      ALLOWED_HOSTS = ['your-server-ip']

      You can save the change and exit nano by holding down the CTRL + x keys and then pressing the y key. Next, we’ll go on to access our web app via a browser.

      Finally, let’s create an administrative user so that you can use the Djano admin interface. Let’s do this with the createsuperuser command:

      • python createsuperuser

      You will be prompted for a username, an email address, and a password for your user.

      Step 5 — Accessing the Django Web App

      With our configuration completed, be sure to navigate back to the directory where is located:

      • cd ~/django-apps/testsite/

      Now, run the following command replacing the your-server-ip text with the IP of your server:

      • python runserver

      Finally, you can navigate to the below link to see what your skeleton website looks like, again replacing the highlighted text with your server’s actual IP:


      Once the page loads, you’ll see the following:

      Django Default Page

      This confirms that Django was properly installed and our test project is working correctly.

      To access the admin interface, add /admin/ to the end of your URL:


      This will take you to a login screen:

      Django admin login

      If you enter the admin username and password that you just created, you will have access to the main admin section of the site:

      Django admin page

      For more information about working with the Django admin interface, please see “How To Enable and Connect the Django Admin Interface.”

      When you are done with testing your app, you can press CTRL + C to stop the runserver command. This will return you to your programming environment.

      When you are ready to leave your Python environment, you can run the deactivate command:

      Deactivating your programming environment will put you back to the terminal command prompt.


      In this tutorial you have successfully installed Django and set up a development environment to begin working on your Django app.

      You now have the foundation needed to get started building Django web applications.

      Source link

      Working with Environment Variables in Vue.js

      While this tutorial has content that we believe is of great benefit to our community, we have not yet tested or
      edited it to ensure you have an error-free learning experience. It’s on our list, and we’re working on it!
      You can help us out by using the “report an issue” button at the bottom of the tutorial.

      In this post, we’ll learn how to work with distinct configurations between development and production mode for Vue.js projects that use the CLI’s webpack template.

      In a web app, we most likely have to access a backend API server through a URL. This URL can be something like http://localhost:8080/api while in development, and in production when the project is deployed. Environment variables allow us for an easy way to change this URL automatically, according to the current state of the project.

      An easy way to use environment variables with Vue and the webpack template is through files with a .env extension. These files become responsible for storing information that’s specific to the environment (development, testing, production,…)

      The majority of this post applies to apps using v2.x of the Vue CLI, but environment variables are just as easy to manage in the Vue CLI v3.

      Using .env Files in Vue

      The simplest way to use .env files in Vue is to create an application that already supports environment files. Let’s use the vue-cli and the webpack template for that.

      With Node 8 or higher installed, run the following, where my-app is your app name:

      $ npx vue-cli init webpack my-app

      This command will create an application with several files ready for use. In this post, we’re focusing only on the environment configuration, which can be accessed in the config directory:

      Project file structure

      There are two files in the config directory: dev.env.js and prod.env.js, and you’ll also have a test.env.js file if you’ve configured tests while initiating the project. These files are used in development and production mode, or in other words, when you are running the application through the npm run dev command, the dev.env.js file is used, and when you compile the project for production with the npm run build command, the prod.env.js file is used instead.

      Let’s change the development file to:


      'use strict'
      const merge = require('webpack-merge')
      const prodEnv = require('./prod.env')
      module.exports = merge(prodEnv, {
        NODE_ENV: '"development"',
        ROOT_API: '"http://localhost/api"'

      Our development environment file has an additional variable called ROOT_API, with the value http://localhost/api.

      Now let’s change the production file to:


      'use strict'
      module.exports = {
        NODE_ENV: '"production"',
        ROOT_API: '""'

      Here we have the same ROOT_API variable, but with a different value, which should only be used in production mode. Note how string variables need the double quotes inside the single quotes.

      Using the Environment Files in Your Code

      After creating the ROOT_API variable, we can use it anywhere in Vue through the global process.env object:


      For example, open the src/components/HelloWorld.vue file and in the <script> tag add the following:

      mounted() {

      After running npm run dev, you will see the console.log information in the browser dev tools:

      Running the app

      If you run the npm run build command, the dist directory will be created with the application ready to be deployed to a production environment, and the variable ROOT_API will display the value, as specified in prod.env.js.

      Thus, we can work with different variables for each different environment, using the ready-made configuration that the webpack template provides us. If you use another template, make sure you find an equivalent feature or use a library like dotenv to manage your environment variables.

      What About Vue CLI 3?

      If your app is using the new Vue CLI, you’ll want to instead have files like .env and at the root of your project and include variables like this:




      The VUE_APP_ prefix is important here, and variables without that prefix won’t be available in your app.

      Source link