One place for hosting & domains

      January 2019

      How To Create an OAuth App with the Linode Python API Library


      Updated by Linode

      Contributed by

      Linode

      Linode supports the OAuth 2 authorization protocol. OAuth 2 allows a user to safely grant a third-party app permission to act on their behalf. This means that a user could authorize an app to access data and / or make changes to their Linode account and services that are exposed by the Linode APIv4. For example, an app could create or destroy Linodes, manage a NodeBalancer, or alter a domain.

      This guide will show you how to create a simple OAuth application using Flask and the Linode Python API library. This app allows a user to log in with their Linode account and create a Linode with a StackScript. The complete code for this example is available in the Linode APIv4 Python library example repository.

      Before You Begin

      1. Normally, in order to create an OAuth app with Linode your server must have HTTPS enabled. The only exceptions to this rule are localhost addresses, which can use HTTP. As this guide is just a primer and is not intended to supply production ready code, we will be working with a local workstation, using localhost. If you choose to create an app for production, you will need to generate SSL certificates for HTTPS access.

      2. Ensure that Python 3 is installed on your workstation.

      Obtaining a Client ID and a Client Secret

      In order for Linode to verify the identity of your app, called a client, you will need to generate a set of credentials, specifically a client ID and a client secret.

      1. Log in to the Linode Cloud Manager and navigate to your Account Profile.

        OAuth Account Profile

      2. From there, click on the My Apps tab and select Create My App. You will be prompted to supply a label for your app and a callback URL. We will discuss the role of the callback URL in depth later in this guide. For now you can supply the following URL:

        http://localhost:5000/auth_callback
        

        Leave Public unchecked and click Submit.

        OAuth Account Profile

      3. A window will appear with your client secret. Copy this down somewhere secure, as once you exit this window you will not be able to retrieve the client secret again, and will be forced to generate a new one.

        OAuth Account Profile

      4. Once you exit the client secret window your app will appear as part of a list of apps. Note your client ID, as this is the last piece of information you will need to verify your app’s identity.

        OAuth Account Profile

      In summary, you should have these three bits of information, with values similar to the ones provided here:

      OAuth 2 Authentication Exchange

      The OAuth 2 workflow is a series of exchanges between your third-party app and Linode. Below is an explanation of these exchanges.

      1. The end user visits your client application’s website and attempts to login.
      2. Your client application redirects the end user to the authentication server (https://login.linode.com) with your client application’s client ID and requested OAuth scopes, which appear in the URL of the login page.
      3. The end user inputs their username and password to the authorization server and authorizes the login.
      4. The authorization server redirects the end user back to your client application with a temporary authorization code (sometimes called an exchange code) in the URL.
      5. The client application issues a POST request to the authentication server containing the authorization code and the client application’s client secret.
      6. The authentication server responds to the client application with a newly issued OAuth access token.

      In the following sections you will write the code to perform each one of these steps, using the Linode Python API library.

      Setup Your Development Environment

      1. Create a project folder and move into that folder.

        mkdir ~/linode-oauth-project && cd ~/linode-oauth-project
        
      2. For this project, you will need to use pip to download and install the required Python libraries. Install pip if you do not already have it:

        apt install python-pip
        
      3. Install the required Python libraries:

        pip install flask flask-session linode_api4
        

      Configure Your App

      In a text editor, create a file named config.py. Add the following variables and values, being sure to change the values to your own.

      The StackScript used in this example is for demo purposes. To explore other available StackScripts, visit the Linode StackScript Library. Note that the stackscript_id does not have quotation marks around it. The secret key is used for serializing session data, and should be a value only you know.

      config.py
      1
      2
      3
      4
      5
      
      client_id = 'ce571a8cdad1ba4a0a7d'
      client_secret = 'fab8e2222e83b9b2f50a76012122ec20a5acb005ed088f3fccda2c9c2c4e1cbd'
      stackscript_id = 320826
      application_name = 'my-application-name'
      secret_key = 'my-secret-key'

      Author an OAuth2 App

      In this section, you will write the code for the app.

      Include Imports

      Ensure you are in the linode-oauth-project directory and create and open a file called app.py in the text editor of your choice. Include the following libraries:

      app.py
      1
      2
      3
      4
      5
      6
      
      import re
      from flask import Flask, redirect, request, render_template, session, send_from_directory
      from flask_session import Session
      from linode_api4 import (LinodeClient, LinodeLoginClient, StackScript, Image, Region, Type, OAuthScopes)
      
      import config

      Set Up Flask and Session Key

      Copy in the following code to set up Flask and the session secret key:

      app.py
      1
      2
      3
      4
      
      ...
      
      app=Flask(__name__)
      app.config['SECRET_KEY'] = config.secret_key

      Create a Function to Return the Linode Login Client

      In app.py add the following function to return the LinodeLoginClient class. The LinodeLoginClient class is the library’s OAuth interface. Note that we are passing the client_id and client_secret parameters from our config.py file to the class:

      ~/linode-oauth-project/app.py
      1
      2
      3
      4
      
      ...
      
      def get_login_client():
          return LinodeLoginClient(config.client_id, config.client_secret)

      Create an Index Route

      In Flask you can create HTTP endpoints with routes. The index route, defined in the code below at the document root /, will be the route the user will see when they navigate to http://localhost:5000/. This route will be responsible for displaying the available Linode plan types, the available regions, and the StackScript-compatible images that a user will choose from when creating their new Linode.

      To query a list of available plan types and regions you can use the LinodeClient class, which is an interface for Linode’s APIv4. Viewing the Linode plan types and regions does not require any sort of authorization, so you can provide a dummy value of no-token to instantiate the class:

      ~/linode-oauth-project/app.py
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      
      ...
      
      @app.route('/')
      def index():
          client = LinodeClient('no-token')
          types = client.linode.types(Type.label.contains("Linode"))
          regions = client.regions()
          stackscript = StackScript(client, config.stackscript_id)
          return render_template('configure.html',
              types=types,
              regions=regions,
              application_name=config.application_name,
              stackscript=stackscript
          )

      It is important to note that the two API queries in the above code are slightly different from one another. The client.regions method is a top-level method, just as it appears in the Linode API. The client.linode.types method, on the other hand, is part of the Linode group, which is a collection of methods that deal with Linodes. Again, this is because Linode endpoints are grouped that way in the API. Some methods in the Linode Python library are top level, such as domain_create, while others, like networking.ip_assign, are part of a group. For more information on the top-level methods and groupings, consult the library documentation.

      In addition to querying the API, the above route also renders the configure.html template by passing it the types, regions, application name, and StackScript object. The StackScript object contains a list of StackScript compatible images. We will cover templating in a later section.

      Create a Login Route

      Next, create a login route in app.py. This route will perform two functions. First, it will serialize the user’s plan type, region, and image selections into the session.

      Second, this route will redirect the user to Linode’s login page where they will be prompted to authorize your client app and the scopes you have requested for it. Scopes are sets of permissions that define the access level of your client app. For instance, to create a Linode, your end user must authorize the OAuthScopes.Linodes.create scope.

      ~/linode-oauth-project/app.py
      1
      2
      3
      4
      5
      6
      7
      8
      9
      
      ...
      
      @app.route('/', methods=["POST"])
      def start_auth():
          login_client = get_login_client()
          session['dc'] = request.form['region']
          session['distro'] = request.form['distribution']
          session['type'] = request.form['type']
          return redirect(login_client.generate_login_url(scopes=OAuthScopes.Linodes.create))

      When the user returns to your app from the Linode login page, they will be directed to the callback URL.

      Note

      Below is a list of available scopes:

      • OAuthScopes.Linodes
      • OAuthScopes.Domains
      • OAuthScopes.StackScripts
      • OAuthScopes.Users
      • OAuthScopes.NodeBalancers
      • OAuthScopes.Tokens
      • OAuthScopes.IPs
      • OAuthScopes.Tickets
      • OAuthScopes.Clients
      • OAuthScopes.Account
      • OAuthScopes.Events
      • OAuthScopes.Volumes

      Each scope is broken into five permissions: view, create, modify, delete, and all. The all permission encompasses the other four permissions.

      Manage the OAuth 2 Callback URL

      The OAuth 2 callback URL has two main responsibilities. Its first responsibility is to help prove the identity of the client application. When a user attempts to log in to Linode through OAuth, instead of redirecting the user back to the page they came from, Linode’s OAuth implementation matches the client ID to the callback URL you have registered with your app on Linode’s system. This ensures that a nefarious third party can’t just steal the client ID, which is public, and attempt to authorize their own app with it.

      The callback URL’s second responsibility is to kick off the process of exchanging an authorization code for an access token. This second process is done over POST, and so it doesn’t require the user to physically leave the page they are returned to after they log in to Linode. Now you will write the code that satisfies this second responsibility.

      In app.py, add the following lines:

      ~/linode-oauth-project/app.py
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      
      ...
      
      @app.route('/auth_callback')
      def auth_callback():
          code = request.args.get('code')
          login_client = get_login_client()
          token, scopes, _, _ = login_client.finish_oauth(code)
      
          # ensure we have sufficient scopes
          if not OAuthScopes.Linodes.create in scopes:
              return render_template('error.html', error='Insufficient scopes granted to deploy {}'
                      .format(config.application_name))
      
          (linode, password) = make_instance(token, session['type'], session['dc'], session['distro'])
      
          get_login_client().expire_token(token)
          return render_template('success.html',
              password=password,
              linode=linode,
              application_name=config.application_name
          )

      Let’s take a look at what each of the parts of this section does.

      First, a route is defined for the callback with @app.route(), then a function called auth_callback is defined that will run whenever this route is accessed:

      ~/linode-oauth-project/app.py
      1
      2
      3
      4
      
      ...
      @app.route('/auth_callback')
      def auth_callback():
      ...

      When the user is returned to the callback URL, an authorization code is appended to the URL. The variable code is set to retrieve this value from the URL’s request arguments:

      ~/linode-oauth-project/app.py
      1
      2
      3
      
      ...
          code = request.args.get('code')
      ...

      Then you retrieve an instance of the LinodeLoginClient class:

      ~/linode-oauth-project/app.py
      1
      2
      3
      
      ...
          login_client = get_login_client()
      ...

      Once you have the LinodeLoginClient class, you can pass the authorization code to the finish_oauth method, which is a helper method that will manage the authorization code to OAuth token exchange. This method returns an OAuth token, and the scopes the user has agreed upon.

      ~/linode-oauth-project/app.py
      1
      2
      3
      
      ...
          token, scopes, _, _ = login_client.finish_oauth(code)
      ...

      The next section compares the scopes your app requested from the user to the scopes returned by Linode’s OAuth login page. If the returned scopes do not include the correct scopes, in this case the OAuthScopes.Linode.create scope, then an error template is rendered and an error message is displayed:

      ~/linode-oauth-project/app.py
      1
      2
      3
      4
      5
      6
      
      ...
          # ensure we have sufficient scopes
          if not OAuthScopes.Linodes.create in scopes:
              return render_template('error.html', error='Insufficient scopes granted to deploy {}'
                      .format(config.application_name))
      ...

      Once your app has determined that it has the correct permissions, it creates the Linode using the Linode plan type, the region, and the image that the app serialized into session storage. You will create the make_instance function in the next step. The make_instance function returns the linode object, which contains the Linode’s label, group, and IP address, and the function also returns a randomly generated password:

      ~/linode-oauth-project/app.py
      1
      2
      3
      
      ...
          (linode, password) = make_instance(token, session['type'], session['dc'], session['distro'])
      ...

      Once the Linode has been created, the app expires the OAuth access token. Expiring tokens after use is a strong security measure but if your app is performing many actions on behalf of the user, you might find that time-based expiration scheme is more suitable to your needs. The app then renders the success template by passing it the linode object, the password, and application name:

      ~/linode-oauth-project/app.py
      1
      2
      3
      4
      5
      6
      7
      
      ...
          get_login_client().expire_token(token)
          return render_template('success.html',
              password=password,
              linode=linode,
              application_name=config.application_name
          )

      Create a Function to Deploy a Linode

      Now, create the make_instance function that you referenced above:

      ~/linode-oauth-project/app.py
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      
      ...
      
      def make_instance(token, type_id, region_id, distribution_id):
          client = LinodeClient('{}'.format(token))
          stackscript = StackScript(client, config.stackscript_id)
          (linode, password) = client.linode.instance_create(type_id, region_id,
                  group=config.application_name,
                  image=distribution_id, stackscript=stackscript.id)
      
          if not linode:
              raise RuntimeError("it didn't work")
          return linode, password

      The make_instance function takes an OAuth access token, the type ID, the region ID, and the image (Linux distribution) ID as parameters. It creates an instance of the LinodeClient class, and unlike the instance of LinodeClient used earlier in the guide, this one requires an OAuth token because you will be using it to create a Linode. The function then creates a Linode using the linode.instance_create method, returning the linode object and the password.

      Finally, if there was an error with the creation of the Linode, the if not linode statement will raise a runtime error.

      Set the name Variable

      At the end of your app.py, paste in the following code to make sure you can run your app:

      ~/linode-oauth-project/app.py
      1
      2
      3
      
      if __name__ == '__main__':
          app.debug=True
          app.run()

      Create App Templates

      Now that you have written the backend code for your app, you’ll need to create a frontend user interface. Begin by creating a templates directory in your project directory and moving into it:

      mkdir ~/linode-oauth-project/templates && cd ~/linode-oauth-project/templates
      

      Using your preferred text editor, create and open base.html. This will be the base template from which your other templates will inherit their stylesheets and JavaScript files:

      ~/linode-oauth-project/templates/base.html
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      53
      54
      55
      56
      57
      58
      59
      60
      61
      62
      63
      64
      65
      66
      67
      
      <html>
      <head>
          <title>Install On Linode</title>
          <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css"
              integrity="sha384-1q8mTJOASx8j1Au+a5WDVnPi2lkFfwwEAa8hDDdjZlpLegxhjVME1fgjWPGmkzs7" crossorigin="anonymous">
          <style>
              body{
                  text-align: center;
                  background-color: #333333;
              }
              .form-group{
                  display: inline-block;
                  text-align: left;
                  width: 250px;
                  border: 1px solid #cccccc;
                  margin: 5px;
                  padding: 5px;
              }
              .form-group label{
                  color: #337ab7;
              }
              .form-group select{
                  font-size: 16px;
                  outline: none;
                  border: 0px solid #000000;
                  box-shadow: inset 0 1px 1px rgba(0,0,0,0);
                  -webkit-box-shadow: inset 0 1px 1px rgba(0,0,0,0);
              }
              .form-group select:focus{
                  box-shadow: inset 0 1px 1px rgba(0,0,0,0);
                  -webkit-box-shadow: inset 0 1px 1px rgba(0,0,0,0);
              }
              .btn-lg{
                  border-radius: 0px;
                  margin-top: 20px;
              }
              .row{
                  margin-bottom: 20px
              }
              .pop{
                  color: #337ab7;
                  font-weight: bold
              }
              code{
                  color: #337ab7;
                  background-color: #eeeeee
              }
              .boxy{
                  border: 1px solid #cccccc;
                  width: 400px;
                  background-color: #f9f9f9;
                  margin: auto;
                  padding: 10px;
              }
          </style>
      </head>
      <body>
          <div class='container' style='background-color: white; border-left: grey; border-right: grey; height: 100%; padding: 20px;'>
              {% block content %}
              {% endblock %}
          </div>
      
          <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
          <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js"
              integrity="sha384-0mSbJDEHialfmuBBQP6A4Qrprq5OVfW37PRR3j5ELqxss1yVqOtnepnHVP9aJ7xS"
              crossorigin="anonymous"></script>
      </body>

      The important thing to note in the above template is the Jinja2 templating tags. They are:

      {% block content %}
      {% endblock %}
      

      As you will see, any template that extends the base.html template and includes code between the opening and closing content block, will render the code laid out by base.html.

      Create a file called configure.html, which will be the UI a user will see when they reach the document root endpoint (/). Copy in the following code:

      templates/configure.html
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      
      {% extends 'base.html' %}
      {% block content %}
          <form method="POST">
              <div class='row'>
                  <h1>Deploy <span style="color: #337ab7;">{{application_name}}</span> to a Linode</h1>
                  <p>
                      This will create a brand new Linode running {{application_name}} on your
                      account and give you the credentials.
                  </p>
              </div>
              <div class='row'>
                  <div class='form-group'>
                      <label for='type'>Type</label>
                      <select name='type'i id='type' class='form-control'
                          onblur="blurring(this)" onfocus="focusing(this)">
                          {% for s in types %}
                              <option value="{{s.id}}">{{s.label}}</option>
                          {% endfor %}
                      </select>
                  </div>
                  <div class='form-group'>
                      <label for='region'>Region</label>
                      <select name='region' id='region' class='form-control'
                          onblur="blurring(this)" onfocus="focusing(this)">
                          {% for o in regions %}
                              <option value="{{o.id}}">{{o.id}}</option>
                          {% endfor %}
                      </select>
                  </div>
                  <div class='form-group'>
                      <label for='distribution'>Images</label>
                      <select name='distribution' id='distribution' class='form-control'
                          onblur="blurring(this)" onfocus="focusing(this)">
                          {% for d in stackscript.images %}
                              <option value="{{d.id.id}}">{{d.id.id}}</option>
                          {% endfor %}
                      </select>
                  </div>
              </div>
              <div class='row'>
                  <input type="submit" value="Deploy Linode" class='btn btn-primary btn-lg'/>
              </div>
          </form>
          <script>
              function focusing(ele){
                  ele.parentElement.style.borderColor = "#337ab7";
              }
              function blurring(ele){
                  ele.parentElement.style.borderColor = "#cccccc";
              }
          </script>
      {% endblock %}

      Here the template begins with two statements: {% extends 'base.html' %} and a {% block content %} statement. These two tags tell Jinja2 to extend the code within base.html, and to place everything within {% block content %} ... {% endblock %} in configure.html between the corresponding {% block content %} ... {% endblock %} tags in base.html.

      configure.html includes Jinja2 logic, with the inclusion of for statements like {% for o in regions %}. These statements are like for statements in other languages, and are used to iterate over an array or list. In this example, it is iterating over the regions that we passed to the template from the index route. configure.html also contains variables, which are denoted by double curly brackets: {{ s.id }}.

      Create another file called error.html. This will be the template that appears whenever there is an error in the Linode deployment. Copy in the following code:

      templates/error.html
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      
      {% extends 'base.html' %}
      {% block content %}
          <div class='row'>
              <h1 class="pop">Error</h1>
              <p>{{error}}</p>
          </div>
          <div class='row' style='margin-top: 20px'>
              <a href='/' class='btn btn-lg btn-default'>Try Again</a>
          </div>
      {% endblock %}

      This template works the same way that configure.html does, by extending base.html and providing its own content block.

      Lastly, create another file called success.html. This file follows the pattern set by configure.html and error.html, and will present the user with a confirmation message whenever a Linode is successfully created. This message includes the Linode’s label, group, IP address, and password:

      templates/success.html
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      
      {% extends 'base.html' %}
      {% block content %}
          <div class='row'>
              <h1>Success!</h1>
              <p>{{application_name}} has been deployed to <span class="pop">{{linode.label}}</span> in the {{linode.group}} group.</p>
          </div>
          <div class='row'>
              <div class='boxy'>
                  <p>You can access your Linode with the following command:</p>
                  <code>ssh root@{{linode.ipv4[0]}}</code>
                  <br />
                  <br />
                  <p>Your root password is:</p>
                  <code>{{password}}</code>
              </div>
          </div>
      {% endblock %}

      Run Your App

      You are now ready to run your app. Change back to your project’s main directory:

      cd ~/linode-oauth-project
      

      Run the app.py script:

      python3 app.py
      

      Open your browser to the following URL:

      http://localhost:5000/
      

      You should be greeted with your new app. Select a plan, a region, and an image to deploy a Linode using the Linode API Python library.

      Next Steps

      The app you’ve created shows off some of the aspects of the Linode API Python library. You can use LinodeLoginClient to authorize your OAuth app with the appropriate scopes, and can create Linodes through the use of LinodeClient.

      In extending this app, you might want to add multiple functionalities, like creating NodeBalancers from a list of available Linodes, or managing domains. To achieve this goal you’ll probably want to separate the login logic from the Linode creation logic. One way to do this would be store the OAuth token in the session, implementing a time-based expiration mechanism to expire your tokens instead.

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.



      Source link

      An Introduction to Service Meshes


      Introduction

      A service mesh is an infrastructure layer that allows you to manage communication between your application’s microservices. As more developers work with microservices, service meshes have evolved to make that work easier and more effective by consolidating common management and administrative tasks in a distributed setup.

      Taking a microservice approach to application architecture involves breaking your application into a collection of loosely-coupled services. This approach offers certain benefits: teams can iterate designs and scale quickly, using a wider range of tools and languages. On the other hand, microservices pose new challenges for operational complexity, data consistency, and security.

      Service meshes are designed to address some of these challenges by offering a granular level of control over how services communicate with one another. Specifically, they offer developers a way to manage:

      • Service discovery
      • Routing and traffic configuration
      • Encryption and authentication/authorization
      • Metrics and monitoring

      Though it is possible to do these tasks natively with container orchestrators like Kubernetes, this approach involves a greater amount of up-front decision-making and administration when compared to what service mesh solutions like Istio and Linkerd offer out of the box. In this sense, service meshes can streamline and simplify the process of working with common components in a microservice architecture. In some cases they can even extend the functionality of these components.

      Why Services Meshes?

      Service meshes are designed to address some of the challenges inherent to distributed application architectures.

      These architectures grew out of the three-tier application model, which broke applications into a web tier, application tier, and database tier. At scale, this model has proved challenging to organizations experiencing rapid growth. Monolithic application code bases can grow to be unwieldy “big balls of mud”, posing challenges for development and deployment.

      In response to this problem, organizations like Google, Netflix, and Twitter developed internal “fat client” libraries to standardize runtime operations across services. These libraries provided load balancing, circuit breaking, routing, and telemetry — precursors to service mesh capabilities. However, they also imposed limitations on the languages developers could use and required changes across services when they themselves were updated or changed.

      A microservice design avoids some of these issues. Instead of having a large, centralized application codebase, you have a collection of discretely managed services that represent a feature of your application. Benefits of a microservice approach include:

      • Greater agility in development and deployment, since teams can work on and deploy different application features independently.
      • Better options for CI/CD, since individual microservices can be tested and redeployed independently.
      • More options for languages and tools. Developers can use the best tools for the tasks at hand, rather than being restricted to a given language or toolset.
      • Ease in scaling.
      • Improvements in uptime, user experience, and stability.

      At the same time, microservices have also created challenges:

      • Distributed systems require different ways of thinking about latency, routing, asynchronous workflows, and failures.
      • Microservice setups cannot necessarily meet the same requirements for data consistency as monolithic setups.
      • Greater levels of distribution necessitate more complex operational designs, particularly when it comes to service-to-service communication.
      • Distribution of services increases the surface area for security vulnerabilities.

      Service meshes are designed to address these issues by offering coordinated and granular control over how services communicate. In the sections that follow, we’ll look at how service meshes facilitate service-to-service communication through service discovery, routing and internal load balancing, traffic configuration, encryption, authentication and authorization, and metrics and monitoring. We will use Istio’s Bookinfo sample application — four microservices that together display information about particular books — as a concrete example to illustrate how service meshes work.

      Service Discovery

      In a distributed framework, it’s necessary to know how to connect to services and whether or not they are available. Service instance locations are assigned dynamically on the network and information about them is constantly changing as containers are created and destroyed through autoscaling, upgrades, and failures.

      Historically, there have been a few tools for doing service discovery in a microservice framework. Key-value stores like etcd were paired with other tools like Registrator to offer service discovery solutions. Tools like Consul iterated on this by combining a key-value store with a DNS interface that allows users to work directly with their DNS server or node.

      Taking a similar approach, Kubernetes offers DNS-based service discovery by default. With it, you can look up services and service ports, and do reverse IP lookups using common DNS naming conventions. In general, an A record for a Kubernetes service matches this pattern: service.namespace.svc.cluster.local. Let’s look at how this works in the context of the Bookinfo application. If, for example, you wanted information on the details service from the Bookinfo app, you could look at the relevant entry in the Kubernetes dashboard:

      Details Service in Kubernetes Dash

      This will give you relevant information about the Service name, namespace, and ClusterIP, which you can use to connect with your Service even as individual containers are destroyed and recreated.

      A service mesh like Istio also offers service discovery capabilities. To do service discovery, Istio relies on communication between the Kubernetes API, Istio’s own control plane, managed by the traffic management component Pilot, and its data plane, managed by Envoy sidecar proxies. Pilot interprets data from the Kubernetes API server to register changes in Pod locations. It then translates that data into a canonical Istio representation and forwards it onto the sidecar proxies.

      This means that service discovery in Istio is platform agnostic, which we can see by using Istio’s Grafana add-on to look at the details service again in Istio’s service dashboard:

      Details Service Istio Dash

      Our application is running on a Kubernetes cluster, so once again we can see the relevant DNS information about the details Service, along with other performance data.

      In a distributed architecture, it’s important to have up-to-date, accurate, and easy-to-locate information about services. Both Kubernetes and service meshes like Istio offer ways to obtain this information using DNS conventions.

      Routing and Traffic Configuration

      Managing traffic in a distributed framework means controlling how traffic gets to your cluster and how it’s directed to your services. The more control and specificity you have in configuring external and internal traffic, the more you will be able to do with your setup. For example, in cases where you are working with canary deployments, migrating applications to new versions, or stress testing particular services through fault injection, having the ability to decide how much traffic your services are getting and where it is coming from will be key to the success of your objectives.

      Kubernetes offers different tools, objects, and services that allow developers to control external traffic to a cluster: kubectl proxy, NodePort, Load Balancers, and Ingress Controllers and Resources. Both kubectl proxy and NodePort allow you to quickly expose your services to external traffic: kubectl proxy creates a proxy server that allows access to static content with an HTTP path, while NodePort exposes a randomly assigned port on each node. Though this offers quick access, drawbacks include having to run kubectl as an authenticated user, in the case of kubectl proxy, and a lack of flexibility in ports and node IPs, in the case of NodePort. And though a Load Balancer optimizes for flexibility by attaching to a particular Service, each Service requires its own Load Balancer, which can be costly.

      An Ingress Resource and Ingress Controller together offer a greater degree of flexibility and configurability over these other options. Using an Ingress Controller with an Ingress Resource allows you to route external traffic to Services and configure internal routing and load balancing. To use an Ingress Resource, you need to configure your Services, the Ingress Controller and LoadBalancer, and the Ingress Resource itself, which will specify the desired routes to your Services. Currently, Kubernetes supports its own Nginx Controller, but there are other options you can choose from as well, managed by Nginx, Kong, and others.

      Istio iterates on the Kubernetes Controller/Resource pattern with Istio Gateways and VirtualServices. Like an Ingress Controller, a Gateway defines how incoming traffic should be handled, specifying exposed ports and protocols to use. It works in conjunction with a VirtualService, which defines routes to Services within the mesh. Both of these resources communicate information to Pilot, which then forwards that information to the Envoy proxies. Though they are similar to Ingress Controllers and Resources, Gateways and VirtualServices offer a different level of control over traffic: instead of combining Open Systems Interconnection (OSI) layers and protocols, Gateways and VirtualServices allow you to differentiate between OSI layers in your settings. For example, by using VirtualServices, teams working with application layer specifications could have a separation of concerns from security operations teams working with different layer specifications. VirtualServices make it possible to separate work on discrete application features or within different trust domains, and can be used for things like canary testing, gradual rollouts, A/B testing, etc.

      To visualize the relationship between Services, you can use Istio’s Servicegraph add-on, which produces a dynamic representation of the relationship between Services using real-time traffic data. The Bookinfo application might look like this without any custom routing applied:

      Bookinfo service graph

      Similarly, you can use a visualization tool like Weave Scope to see the relationship between your Services at a given time. The Bookinfo application without advanced routing might look like this:

      Weave Scope Service Map

      When configuring application traffic in a distributed framework, there are a number of different solutions — from Kubernetes-native options to service meshes like Istio — that offer various options for determining how external traffic will reach your application resources and how these resources will communicate with one another.

      Encryption and Authentication/Authorization

      A distributed framework presents opportunities for security vulnerabilities. Instead of communicating through local internal calls, as they would in a monolithic setup, services in a microservice architecture communicate information, including privileged information, over the network. Overall, this creates a greater surface area for attacks.

      Securing Kubernetes clusters involves a range of procedures; we will focus on authentication, authorization, and encryption. Kubernetes offers native approaches to each of these:

      • Authentication: API requests in Kubernetes are tied to user or service accounts, which need to be authenticated. There are several different ways to manage the necessary credentials: Static Tokens, Bootstrap Tokens, X509 client certificates, and external tools like OpenID Connect.
      • Authorization: Kubernetes has different authorization modules that allow you to determine access based on things like roles, attributes, and other specialized functions. Since all requests to the API server are denied by default, each part of an API request must be defined by an authorization policy.
      • Encryption: This can refer to any of the following: connections between end users and services, secret data, endpoints in the Kubernetes control plane, and communication between worker cluster components and master components. Kubernetes has different solutions for each of these:

      Configuring individual security policies and protocols in Kubernetes requires administrative investment. A service mesh like Istio can consolidate some of these activities.

      Istio is designed to automate some of the work of securing services. Its control plane includes several components that handle security:

      • Citadel: manages keys and certificates.
      • Pilot: oversees authentication and naming policies and shares this information with Envoy proxies.
      • Mixer: manages authorization and auditing.

      For example, when you create a Service, Citadel receives that information from the kube-apiserver and creates SPIFFE certificates and keys for this Service. It then transfers this information to Pods and Envoy sidecars to facilitate communication between Services.

      You can also implement some security features by enabling mutual TLS during the Istio installation. These include strong service identities for cross- and inter-cluster communication, secure service-to-service and user-to-service communication, and a key management system that can automate key and certificate creation, distribution, and rotation.

      By iterating on how Kubernetes handles authentication, authorization, and encryption, service meshes like Istio are able to consolidate and extend some of the recommended best practices for running a secure Kubernetes cluster.

      Metrics and Monitoring

      Distributed environments have changed the requirements for metrics and monitoring. Monitoring tools need to be adaptive, accounting for frequent changes to services and network addresses, and comprehensive, allowing for the amount and type of information passing between services.

      Kubernetes includes some internal monitoring tools by default. These resources belong to its resource metrics pipeline, which ensures that the cluster runs as expected. The cAdvisor component collects network usage, memory, and CPU statistics from individual containers and nodes and passes that information to kubelet; kubelet in turn exposes that information via a REST API. The Metrics Server gets this information from the API and then passes it to the kube-aggregator for formatting.

      You can extended these internal tools and monitoring capabilities with a full metrics solution. Using a service like Prometheus as a metrics aggregator allows you to build directly on top of the Kubernetes resource metrics pipeline. Prometheus integrates directly with cAdvisor through its own agents, located on the nodes. Its main aggregation service collects and stores data from the nodes and exposes it though dashboards and APIs. Additional storage and visualization options are also available if you choose to integrate your main aggregation service with backend storage, logging, and visualization tools like InfluxDB, Grafana, ElasticSearch, Logstash, Kibana, and others.

      In a service mesh like Istio, the structure of the full metrics pipeline is part of the mesh’s design. Envoy sidecars operating at the Pod level communicate metrics to Mixer, which manages policies and telemetry. Additionally, Prometheus and Grafana services are enabled by default (though if you are installing Istio with Helm you will need to specify granafa.enabled=true during installation). As is the case with the full metrics pipeline, you can also configure other services and deployments for logging and viewing options.

      With these metric and visualization tools in place, you can access current information about services and workloads in a central place. For example, a global view of the BookInfo application might look like this in the Istio Grafana dashboard:

      Bookinfo services from Grafana dash

      By replicating the structure of a Kubernetes full metrics pipeline and simplifying access to some of its common components, service meshes like Istio streamline the process of data collection and visualization when working with a cluster.

      Conclusion

      Microservice architectures are designed to make application development and deployment fast and reliable. Yet an increase in inter-service communication has changed best practices for certain administrative tasks. This article discusses some of those tasks, how they are handled in a Kubernetes-native context, and how they can be managed using a service mesh — in this case, Istio.

      For more information on some of the Kubernetes topics covered here, please see the following resources:

      Additionally, the Kubernetes and Istio documentation hubs are great places to find detailed information about the topics discussed here.



      Source link

      How To Sync and Share Your Files with Seafile on Debian 9


      The author selected Electronic Frontier Foundation Inc to receive a donation as part of the Write for DOnations program.

      Introduction

      Seafile is an open-source, self-hosted, file synchronization and sharing platform. Users can store and optionally encrypt data on their own servers with storage space as the only limitation. With Seafile you can share files and folders using cross-platform syncing and password-protected links to files with expiration dates. A file-versioning feature means that users can restore deleted and modified files or folders.

      In this tutorial, you will install and configure Seafile on a Debian 9 server. You will use MariaDB (the default MySQL variant on Debian 9) to store data for the different components of Seafile, and Apache as the proxy server to handle the web traffic. After completing this tutorial, you will be able use the web interface to access Seafile from desktop or mobile clients, allowing you to sync and share your files with other users or groups on the server or with the public.

      Prerequisites

      Before you begin this guide, you’ll need the following:

      • One Debian 9 server with a minimum of 2GB of RAM set up by following this Initial Server Setup with Debian 9 tutorial, including a sudo non-root user and a firewall.
      • An Apache web server with a virtual host configured for the registered domain by following How To Install the Apache Web Server on Debian 9.
      • An SSL certificate installed on your server by following this How To Secure Apache with Let’s Encrypt on Debian 9 tutorial.
      • A fully registered domain name. This tutorial will use example.com throughout.
      • Both of the following DNS records set up for your server. You can follow this introduction to DigitalOcean DNS for details on how to add them.

        • An A record with example.com pointing to your server’s public IP address.
        • An A record with www.example.com pointing to your server’s public IP address.
      • A MariaDB database server installed and configured. Follow the steps in the How To Install MariaDB on Debian 9 tutorial. Skip Step 3 of this tutorial — “(Optional) Adjusting User Authentication and Privileges”. You will only be making local connections to the database server, so changing the authentication method for the root user is not necessary.

      Step 1 — Creating Databases for the Seafile Components

      Seafile requires three components in order to work properly. These three components are:

      • Seahub: Seafile’s web frontend, written in Python using the Django web framework. From Seahub you can access, manage, and share your files using a web browser.
      • Seafile server: The data service daemon that manages the raw file upload, download, and synchronization. You do not interact with the server directly, but use one of the client programs or the Seahub web interface.
      • Ccnet server: The RPC service daemon to enable internal communication between the different components of Seafile. For example, when you use Seahub, it is able to access data from the Seafile server using the Ccnet RPC service.

      Each of these components stores its data separately in its own database. In this step you will create the three MariaDB databases and a user before proceeding to set up the server.

      First, log in to the server using SSH with your username and IP address:

      ssh sammy@your_server_ip
      

      Connect to the MariaDB database server as administrator (root):

      At the MariaDB prompt, use the following SQL command to create the database user:

      • CREATE USER 'sammy'@'localhost' IDENTIFIED BY 'password';

      Next, you will create the following databases to store the data of the three Seafile components:

      • ccnet-db for the Ccnet server.
      • seahub-db for the Seahub web frontend.
      • seafile-db for the Seafile file server.

      At the MariaDB prompt, create your databases:

      • CREATE DATABASE `ccnet-db` CHARACTER SET = 'utf8';
      • CREATE DATABASE `seafile-db` CHARACTER SET = 'utf8';
      • CREATE DATABASE `seahub-db` CHARACTER SET = 'utf8';

      Then, grant all privileges to the Seafile database user to access and make changes in these databases:

      • GRANT ALL PRIVILEGES ON `ccnet-db`.* to `sammy`@localhost;
      • GRANT ALL PRIVILEGES ON `seafile-db`.* to `sammy`@localhost;
      • GRANT ALL PRIVILEGES ON `seahub-db`.* to `sammy`@localhost;

      Exit the MariaDB prompt by typing exit:

      Now that you have created a user and the databases required to store the data for each of the Seafile components, you will install dependencies to download the Seafile server package.

      Step 2 — Installing Dependencies and Downloading Seafile

      Some parts of Seafile are written in Python and therefore require additional Python modules and programs to work. In this step, you will install these required dependencies before downloading and extracting the Seafile server package.

      To install the dependencies using apt run the following command:

      • sudo apt install python-setuptools python-pip python-urllib3 python-requests python-mysqldb ffmpeg

      The python-setuptools and python-pip dependencies oversee installing and managing Python packages. The python-urllib3 and python-requests packages make requests to websites. Finally, the python-mysqldb is a library for using MariaDB from Python and ffmpeg handles multimedia files.

      Seafile requires Pillow, a python library for image processing, and moviepy to handle movie file thumbnails. These modules are not available in the Debian package repository. You will install them manually using pip:

      • sudo pip install Pillow==4.3.0 moviepy

      Now that you have installed the necessary dependencies, you can download the Seafile server package.

      Seafile creates additional directories during setup. To keep them all organized, create a new directory and change into it:

      You can now download the latest version (6.3.4 as of this writing) of the Seafile server from the website by running the following command:

      • wget https://download.seadrive.org/seafile-server_6.3.4_x86-64.tar.gz

      Seafile distributes the download as a compressed tar archive, which means you will need to extract it before proceeding. Extract the archive using tar:

      • tar -zxvf seafile-server_6.3.4_x86-64.tar.gz

      Now change into the extracted directory:

      At this stage, you have downloaded and extracted the Seafile server package and have also installed the necessary dependencies. You are now ready to configure the Seafile server.

      Step 3 — Configuring the Seafile Server

      Seafile needs some information about your setup before you start the services for the first time. This includes details like the domain name, the database configuration, and the path where it will store data. To initiate the series of question prompts to provide this information, you can run the script setup_seafile_mysql.sh, which is included in the archive you extracted in the previous step.

      Run the script using bash:

      • bash setup-seafile-mysql.sh

      Press ENTER to continue.

      The script will now prompt you with a series of questions. Wherever defaults are mentioned, pressing the ENTER key will use that value.

      This tutorial uses Seafile as the server name, but you can change it if necessary.

      Question 1
      
      What is the name of the server?
      It will be displayed on the client. 3 - 15 letters or digits
      [ server name ] Seafile
      

      Enter the domain name for this Seafile instance.

      Question 2
      
      What is the ip or domain of the server?.
      For example: www.mycompany.com, 192.168.1.101
      [ This server's ip or domain ] example.com
      

      For Question 3 press ENTER to accept the default value. If you have set up external storage, for example, using NFS or block storage, you will need to specify the path to that location here instead.

      Question 3
      
      Where do you want to put your seafile data?
      Please use a volume with enough free space
      [ default "/home/sammy/seafile/seafile-data" ]
      

      For Question 4 press ENTER to accept the default value.

      Question 4
      
      Which port do you want to use for the seafile fileserver?
      [ default "8082" ]
      

      The next prompt allows you to confirm the database configuration. You can create new databases or use existing databases for setup. For this tutorial you have created the necessary databases in Step 1, so select option 2 here.

      -------------------------------------------------------
      Please choose a way to initialize seafile databases:
      -------------------------------------------------------
      
      [1] Create new ccnet/seafile/seahub databases
      [2] Use existing ccnet/seafile/seahub databases
      
      [ 1 or 2 ] 2
      

      Questions 6–9 relate to the MariaDB database server. You will only need to provide the username and password of the mysql user that you created in Step 1. Press ENTER to accept the default values for host and port.

      
      What is the host of mysql server?
      
      [ default "localhost" ]
      
      What is the port of mysql server?
      
      [ default "3306" ]
      
      Which mysql user to use for seafile?
      
      [ mysql user for seafile ] sammy
      
      What is the password for mysql user "seafile"?
      
      [ password for seafile ] password
      

      After providing the password, the script will request the names of the Seafile databases. Use ccnet-db, seafile-db, and seahub-db for this tutorial. The script will then verify if there is a successful connection to the databases before proceeding to display a summary of the initial configuration.

      Enter the existing database name for ccnet:
      [ ccnet database ] ccnet-db
      
      verifying user "sammy" access to database ccnet-db ...  done
      
      Enter the existing database name for seafile:
      [ seafile database ] seafile-db
      
      verifying user "sammy" access to database seafile-db ...  done
      
      Enter the existing database name for seahub:
      [ seahub database ] seahub-db
      
      verifying user "sammy" access to database seahub-db ...  done
      
      ---------------------------------
      This is your configuration
      ---------------------------------
      
          server name:            Seafile
          server ip/domain:       example.com
      
          seafile data dir:       /home/sammy/seafile/seafile-data
          fileserver port:        8082
      
          database:               use existing
          ccnet database:         ccnet-db
          seafile database:       seafile-db
          seahub database:        seahub-db
          database user:          sammy
      
      --------------------------------
      Press ENTER to continue, or Ctrl-C to abort
      ---------------------------------
      

      Press ENTER to confirm.

      Output

      Generating ccnet configuration ... done Successly create configuration dir /home/sammy/seafile/ccnet. Generating seafile configuration ... done Generating seahub configuration ... ---------------------------------------- Now creating seahub database tables ... ---------------------------------------- creating seafile-server-latest symbolic link ... done ----------------------------------------------------------------- Your seafile server configuration has been finished successfully. ----------------------------------------------------------------- run seafile server: ./seafile.sh { start | stop | restart } run seahub server: ./seahub.sh { start <port> | stop | restart <port> } ----------------------------------------------------------------- If you are behind a firewall, remember to allow input/output of these tcp ports: ----------------------------------------------------------------- port of seafile fileserver: 8082 port of seahub: 8000 When problems occur, Refer to https://github.com/haiwen/seafile/wiki for information.

      As you will be running Seafile behind Apache, opening ports 8082 and 8000 in the firewall is not necessary, so you can ignore this part of the output.

      You have completed the initial configuration of the server. In the next step, you will configure the Apache web server before starting the Seafile services.

      Step 4 — Configuring the Apache Web Server

      In this step, you will configure the Apache web server to forward all requests to Seafile. Using Apache in this manner allows you to use a URL without a port number, enable HTTPS connections to Seafile, and make use of the caching functionality that Apache provides for better performance.

      To begin forwarding requests, you will need to enable the proxy_http module in the Apache configuration. This module provides features for proxying HTTP and HTTPS requests. The following command will enable the module:

      Note: The Apache rewrite and ssl modules are also required for this setup. You have already enabled these modules as part of configuring Let's Encrypt in the second Apache tutorial listed in the prerequisites section.

      Next, update the virtual host configuration of example.com to forward requests to the Seafile file server and to the Seahub web interface.

      Open the configuration file in a text editor:

      • sudo nano /etc/apache2/sites-enabled/example.com-le-ssl.conf

      The lines from ServerAdmin to SSLCertificateKeyFile are part of the initial Apache and Let's Encrypt configuration that you set up as part of the prerequisite. Add the highlighted content, beginning at Alias and ending with the ProxyPassReverse directive:

      /etc/apache2/sites-enabled/example.com-le-ssl.conf

      
      <IfModule mod_ssl.c>
      <VirtualHost *:443>
          ServerAdmin [email protected]
          ServerName example.com
          ServerAlias www.example.com
          DocumentRoot /var/www/example.com/html
          ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
          CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
      
          Include /etc/letsencrypt/options-ssl-apache.conf
          SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
          SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
      
          Alias /media  /home/sammy/seafile/seafile-server-latest/seahub/media
          <Location /media>
              Require all granted
          </Location>
      
          # seafile fileserver
          ProxyPass /seafhttp http://127.0.0.1:8082
          ProxyPassReverse /seafhttp http://127.0.0.1:8082
          RewriteEngine On
          RewriteRule ^/seafhttp - [QSA,L]
      
          # seahub web interface
          SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
          ProxyPass / http://127.0.0.1:8000/
          ProxyPassReverse / http://127.0.0.1:8000/
      </VirtualHost>
      </IfModule>
      

      The Alias directive maps the URL path example.com/media to a local path in the file system that Seafile uses. The following Location directive enables access to content in this directory. The ProxyPass and ProxyPassReverse directives make Apache act as a reverse proxy for this host, forwarding requests to / and /seafhttp to the Seafile web interface and file server running on local host ports 8000 and 8082 respectively. The RewriteRule directive passes all requests to /seafhttp unchanged and stops processing further rules ([QSA,L]).

      Save and exit the file.

      Test if there are any syntax errors in the virtual host configuration:

      • sudo apache2ctl configtest

      If it reports Syntax OK, then there are no issues with your configuration. Restart Apache for the changes to take effect:

      • sudo systemctl restart apache2

      You have now configured Apache to act as a reverse proxy for the Seafile file server and Seahub. Next, you will update the URLs in Seafile's configuration before starting the services.

      Step 5 — Updating Seafile's Configuration and Starting Services

      As you are now using Apache to proxy all requests to Seafile, you will need to update the URLs in Seafile's configuration files in the conf directory using a text editor before you start the Seafile service.

      Open ccnet.conf in a text editor:

      • nano /home/sammy/seafile/conf/ccnet.conf

      Modify the SERVICE_URL setting in the file to point to the new HTTPS URL without the port number, for example:

      Update /home/sammy/seafile/conf/ccnet.conf

      SERVICE_URL = https://example.com
      

      Save and exit the file once you have added the content.

      Now open seahub_settings.py in a text editor:

      • nano /home/sammy/seafile/conf/seahub_settings.py

      You can now add a FILE_SERVER_ROOT setting in the file to specify the path where the file server is listening for file uploads and downloads:

      Update /home/sammy/seafile/conf/seahub_settings.py

      # -*- coding: utf-8 -*-
      SECRET_KEY = "..."
      FILE_SERVER_ROOT = 'https://example.com/seafhttp'
      # ...
      

      Save and exit seahub_settings.py.

      Now you can start the Seafile service and the Seahub interface:

      • cd /home/sammy/seafile/seafile-server-6.3.4
      • ./seafile.sh start
      • ./seahub.sh start

      As this is the first time you have started the Seahub service, it will prompt you to create an admin account. Enter a valid email address and a password for this admin user:

      Output

      What is the email for the admin account? [ admin email ] [email protected] What is the password for the admin account? [ admin password ] password-here Enter the password again: [ admin password again ] password-here ---------------------------------------- Successfully created seafile admin ---------------------------------------- Seahub is started Done.

      Open https://example.com in a web browser and log in using your Seafile admin email address and password.

      Login screen of the Seafile web interface

      Once logged in successfully, you can access the admin interface or create new users.

      Now that you have verified the web interface is working correctly, you can enable these services to start automatically at system boot in the next step.

      Step 6 — Enabling the Seafile Server to Start at System Boot

      To enable the file server and the web interface to start automatically at boot, you can create the respective systemd service files and activate them.

      Create a systemd service file for the Seafile file server:

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

      Add the following content to the file:

      Create /etc/systemd/system/seafile.service

      [Unit]
      Description=Seafile
      After=network.target mysql.service
      
      [Service]
      Type=forking
      ExecStart=/home/sammy/seafile/seafile-server-latest/seafile.sh start
      ExecStop=/home/sammy/seafile/seafile-server-latest/seafile.sh stop
      User=sammy
      Group=sammy
      
      [Install]
      WantedBy=multi-user.target
      

      Here, the ExectStart and ExecStop lines indicate the commands that run to start and stop the Seafile service. The service will run with sammy as the User and Group. The After line specifies that the Seafile service will start after the networking and MariaDB service has started.

      Save seafile.service and exit.

      Create a systemd service file for the Seahub web interface:

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

      This is similar to the Seafile service. The only difference is that the web interface is started after the Seafile service. Add the following content to this file:

      Create /etc/systemd/system/seahub.service

      [Unit]
      Description=Seafile hub
      After=network.target seafile.service
      
      [Service]
      Type=forking
      ExecStart=/home/sammy/seafile/seafile-server-latest/seahub.sh start
      ExecStop=/home/sammy/seafile/seafile-server-latest/seahub.sh stop
      User=sammy
      Group=sammy
      
      [Install]
      WantedBy=multi-user.target
      

      Save seahub.service and exit.

      You can learn more about systemd unit files in the Understanding Systemd Units and Unit Files tutorial.

      Finally, to enable both the Seafile and Seahub services to start automatically at boot, run the following commands:

      • sudo systemctl enable seafile.service
      • sudo systemctl enable seahub.service

      When the server is rebooted, Seafile will start automatically.

      At this point, you have completed setting up the server, and can now test each of the services.

      Step 7 — Testing File Syncing and Sharing Functionality

      In this step, you will test the file synchronization and sharing functionality of the server you have set up and ensure they are working correctly. To do this, you will need to install the Seafile client program on a separate computer and/or a mobile device.

      Visit the download page on the Seafile website and follow the instructions to install the latest version of the program on your computer. Seafile clients are available for the various distributions of Linux (Ubuntu, Debian, Fedora, Centos/RHEL, Arch Linux), MacOS, and Windows. Mobile clients are available for Android and iPhone/iPad devices from the respective app stores.

      Once you have installed the Seafile client, you can test the file synchronization and sharing functionality.

      Open the Seafile client program on your computer or device. Accept the default location for the Seafile folder and click Next.

      In the next window, enter the server address, username, and password, then click Login.

      At the home page, right click on My Library and click Sync this library. Accept the default value for the location on your computer or device.

      Seafile client — Sync the default library

      Add a file, for example a document or a photo, into the My Library folder. After some time, the file will upload to the server. The following screenshot shows the file photo.jpg copied to the My Library folder.

      Add a file to the default library from the computer

      Now, log in to the web interface at https://example.com and verify that your file is present on the server.

      My Library page to verify file sync

      Click on Share next to the file to generate a download link for this file that you can share.

      You have verified that the file synchronization is working correctly and that you can use Seafile to sync and share files and folders from multiple devices.

      Conclusion

      In this tutorial you set up a private instance of a Seafile server. Now you can start using the server to synchronize files, add users and groups, and share files between them or with the public without relying on an external service.

      When a new release of the server is available, please consult the upgrade section of the manual for steps to perform an upgrade.



      Source link