One place for hosting & domains

      Install

      How to Install Apps on Kubernetes with Helm 3


      Updated by Linode Written by Linode

      How to Install Apps on Kubernetes with Helm

      What is Helm?

      Helm is a tool that assists with installing and managing applications on Kubernetes clusters. It is often referred to as “the package manager for Kubernetes,” and it provides functions that are similar to a package manager for an operating system:

      • Helm prescribes a common format and directory structure for packaging your Kubernetes resources, known as a Helm chart.

      • Helm provides a public repository of charts for popular software. You can also retrieve charts from third-party repositories, author and contribute your own charts to someone else’s repository, or run your own chart repository.

      • The Helm client software offers commands for: listing and searching for charts by keyword, installing applications to your cluster from charts, upgrading those applications, removing applications, and other management functions.

      New for Helm 3

      Here are the biggest changes for Helm 3. For a complete list and more details, see the FAQ.

      • The most notable change in Helm 3 was the removal of Tiller. With role-based access controls (RBAC) enabled by default in Kubernetes 1.6+, Tiller became unnecessary and was removed.

      • Upgrading a chart is better than ever. Helm 3 introduces a 3-way merge patch, an improvement over Helm 2’s 2-way approach. Helm is now able to consider the old manifest, the current state, and the new manifest, instead of just the most recent manifest and the proposed changes. The 3-way merge patch helps to ensure that a user can roll back changes regardless of how they’re applied.

      • Release names in Helm 3 are scoped to the namespace and have a sh.helm.release.v1 prefix.

      • Secrets are used as the default storage driver for releases.

      • The Go import path has changed from k8s.io/helm to helm.sh/helm/v3.

      • requirements.yaml has been folded into Chart.yaml as the dependencies field.

      • Helm 3 now supports Library charts. These are shared by other charts and are intended to be reused to avoid redundancy.

      • Helm 3 has moved to XDG Base Directory Specification. This means instead of Helm 2’s $HELM_HOME location, you will find information stored in the following:

        • XDG_CACHE_HOME
        • XDG_CONFIG_HOME
        • XDG_DATA_HOME
      • Helm Hub – Helm 3 does not come with chart repositories loaded out of the box. Instead there is now a central hub for charts called Helm Hub.

      Migrating from Helm 2 to Helm 3

      Helm has provided a plugin to migrate your projects from Helm 2 to Helm 3 called helm-2to3. This plugin works in three stages. First it migrates the configuration, then the release, then it cleans up the configuration, release data, and Tiller.

      Charts

      The components of a Kubernetes application–deployments, services, ingresses, and other objects–are listed in manifest files (in the YAML file format). Kubernetes does not tell you how you should organize those files, though the Kubernetes documentation does offer a general set of best practices.

      Helm charts are the software packaging format for Helm. A chart specifies a file and directory structure that you follow when packaging your manifests. The structure looks as follows:

      chart-name/
        Chart.yaml
        LICENSE
        README.md
        values.yaml
        charts/
        crds/
        templates/
        templates/NOTES.txt
      
      File or Directory Description
      Chart.yaml General information about the chart, including the chart name, a version number, and a description. Charts can be of two types, application or library. Set this with the type field. Application is the default. You can also set a chart to be deprecated with the optional deprecated field. Note the apiVersion field for Helm 3 will be v2. v1 charts can still be installed by Helm 3 but the dependencies field is located in a separate requirements.yaml file for v1 charts. Note also that the appVersion field is different from the version field, where version references the chart version and appVersion references the application version.
      LICENSE A plain-text file with licensing information for the chart and for the applications installed by the chart. Optional.
      README.md A Markdown file with instructions that a user of a chart may want to know when installing and using the chart, including a description of the app that the chart installs and the template values that can be set by the user. Optional.
      templates/NOTES.txt A plain-text file which will print to a user’s terminal when they install the chart. This text can be used to display post-installation instructions or other information that a user may want to know. Optional.
      charts/ A directory which stores chart dependencies that you manually copy into your project, instead of linking to them from the Chart.yaml file’s dependencies field.
      values.yaml Default values for the variables in your manifests’ templates.
      templates/ Your Kubernetes manifests are stored in the templates/ directory. Helm will interpret your manifests using the Go templating language before applying them to your cluster. You can use the template language to insert variables into your manifests, and users of your chart will be able to enter their own values for those variables.
      Custom Resource Definitions (CRDS) In Helm 3 CRDS are a special type of global object and are installed first. They should be placed in the crds/ directory inside of the chart. You can have multiple CRDs in the same file as long as they are separated by YAML start and end markers. Note, these are only installed once and will not be upgraded or rolled back. Additionally, deleting a CRD deletes all of that CRD’s contents across all namespaces in the cluster. Therefore, Helm does not do this. You can do it manually, carefully. Alternatively, you can skip with the --skip-crds option.

      Releases

      When you tell Helm to install a chart, you can specify variable values to be inserted into the chart’s manifest templates. Helm will then compile those templates into manifests that can be applied to your cluster. When it does this, it creates a new release.

      You can install a chart to the same cluster more than once. Each time you tell Helm to install a chart, it creates another release for that chart. A release can be upgraded when a new version of a chart is available, or even when you just want to supply new variable values to the chart. Helm tracks each upgrade to your release, and it allows you to roll back an upgrade. A release can be easily deleted from your cluster, and you can even roll back release deletions when configured to do so in advanced.

      Helm Client

      The Helm client software issues commands to your cluster. You run the client software on your computer, in your CI/CD environment, or anywhere else you’d like.

      Before You Begin

      Note

      The Linode Kubernetes Engine (LKE) is now in Private Beta. If you are in the beta, you can use LKE to stand up your Kubernetes cluster if you wish. Sign up for the beta here.
      1. Install the Kubernetes CLI (kubectl) on your computer, if it is not already.

      2. You should have a Kubernetes cluster running prior to starting this guide. One quick way to get a cluster up is with Linode’s k8s-alpha CLI command. This guide’s examples only require a cluster with one worker node. We recommend that you create cluster nodes that are at the Linode 4GB tier (g6-standard-2) or higher.

        Caution

        The k8s-alpha CLI is deprecated. On March 31st, 2020, it will be removed from the linode-cli. After March 31, 2020, you will no longer be able to create or manage clusters created by the linode-cli.

        However, you will still be able to successfully manage your clusters using Terraform, which is how the k8s-alpha CLI itself is implemented. The Terraform configuration files that the k8s-alpha CLI creates are stored in your computer’s home folder, under the .k8s-alpha-linode/ directory.

        Other alternatives for creating and managing clusters include:

        This guide also assumes that your cluster has role-based access control (RBAC) enabled. This feature became available in Kubernetes 1.6. It is enabled on clusters created via the k8s-alpha Linode CLI.

        Note

        This guide’s example instructions will also result in the creation of a Block Storage Volume and a NodeBalancer, which are also billable resources. If you do not want to keep using the example application after you finish reviewing your guide, make sure to delete these resources afterward.
      3. You should also make sure that your Kubernetes CLI is using the right cluster context. Run the get-contexts subcommand to check:

        kubectl config get-contexts
        
      4. You can set kubectl to use a certain cluster context with the use-context subcommand and the cluster name that was previously output from the get-contexts subcommand:

        kubectl config use-context your-cluster-name
        
      5. It is beneficial to have a registered domain name for this guide’s example app, but it is not required.

      Install Helm

      Install the Helm Client

      Install the Helm client software on your computer:

      Linux – Run the client installer script that Helm provides:

      curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh
      chmod 700 get_helm.sh
      ./get_helm.sh
      

      macOS – Use Homebrew to install:

      brew install helm
      

      Windows – Use Chocolatey to install:

      choco install kubernetes-helm
      

      Use Helm Charts to Install Apps

      This guide will use the Ghost publishing platform as the example application.

      Search for a Chart

      1. Search the Helm Hub for the Ghost chart:

        helm search hub ghost
        
          
        URL                                     	CHART VERSION	APP VERSION	DESCRIPTION
        https://hub.helm.sh/charts/bitnami/ghost	9.0.3        	3.1.1      	A simple, powerful publishing platform that all...
        
        

        This gives you the URL where the chart is located in the central hub. Here you will find all the information about configuration and setup.

      2. Add the stable repository:

        helm repo add stable https://kubernetes-charts.storage.googleapis.com/
        
      3. Update the repo to ensure you get the latest chart version:

        helm repo update
        
      4. The full name for the chart is stable/ghost. You can inspect the chart for more information:

        helm show readme stable/ghost
        

        This command’s output will resemble the README text available for the Ghost in the official central hub as linked above.

      Install the Chart

      The helm install command is used to install a chart by name. It can be run without any other options, but some charts expect you to pass in configuration values for the chart:

      1. Create a file named ghost-values.yaml on your computer for this snippet:

        ghost-values.yaml
        1
        2
        3
        4
        5
        
        ghostHost: "ghost.example.com"
        ghostEmail: "[email protected]"
        ghostUsername: "admin"
        ghostPassword: "mySecurePassword123!!"
        mariadb.mariadbRootPassword: "secretpassword"

        Replace the value for ghostHost with a domain or subdomain that you own and would like to assign to the app; the value for ghostEmail with your email; the values for ghostUsername and ghostPassword with the credentials you wish to use for logging into your site; and the value for mariabd.mariadbRootPassword for the password you wish to use for logging into the database.

        Note

        If you don’t own a domain name and won’t continue to use the Ghost website after finishing this guide, you can make up a domain for this configuration file.

      2. Run the install command and pass in the configuration file:

        helm install --values=ghost-values.yaml stable/ghost --generate-name
        
      3. The install command returns immediately and does not wait until the app’s cluster objects are ready. You will see output like the following snippet, which shows that the app’s pods are still in the “Pending” state. The text displayed is generated from the contents of the chart’s templates/NOTES.txt file:

          
        NAME: ghost-1576075187
        LAST DEPLOYED: Wed Dec 11 09:39:50 2019
        NAMESPACE: default
        STATUS: deployed
        REVISION: 1
        NOTES:
        1. Get the Ghost URL by running:
        
          echo Blog URL  : http://ghost.example.com/
          echo Admin URL : http://ghost.example.com/ghost
        
        2. Get your Ghost login credentials by running:
        
          echo Email:    [email protected]
          echo Password: $(kubectl get secret --namespace default ghost-1576075187 -o jsonpath="{.data.ghost-password}" | base64 --decode)
        
        
      4. Helm has created a new release and assigned it a random name. Run the ls command to get a list of all of your releases:

        helm ls
        

        The output will look as follows:

          
        NAME            	NAMESPACE	REVISION	UPDATED                             	STATUS  	CHART      	APP VERSION
        ghost-1576075187	default  	1       	2019-12-11 09:39:50.168546 -0500 EST	deployed	ghost-9.0.3	3.1.1
        
        
      5. You can check on the status of the release by running the status command:

        helm status ghost-1576075187
        

        This command will show the same output that was displayed after the helm install command, but the current state of the cluster objects will be updated.

      Access Your App

      1. Navigate to the NoadBalancer that was created in Cloud Manager and find the IP address.

        Find the IP address of the NodeBalancer in Cloud Manager

      2. The LoadBalancer that was created for the app will be displayed. Because this example uses a cluster created with Linode’s k8s-alpha CLI (which pre-installs the Linode CCM), the LoadBalancer will be implemented as a Linode NodeBalancer.

      3. Copy the value under the IP Address column for the NoadBalancer and then paste it into your web browser. You should see the Ghost website:

        Ghost home page

      4. Revisit the output from the status command. Instructions for logging into your Ghost website will be displayed:

          
        [...]
        1. Get the Ghost URL by running:
        
          echo Blog URL  : http://ghost.example.com/
          echo Admin URL : http://ghost.example.com/ghost
        
        2. Get your Ghost login credentials by running:
        
          echo Email:    [email protected]
          echo Password: $(kubectl get secret --namespace default ghost-1576075187 -o jsonpath="{.data.ghost-password}" | base64 --decode)
        
        
      5. If you haven’t set up DNS for your site yet, you can instead access the admin interface by visiting the ghost URL on your LoadBalancer IP address (e.g. http://104.237.148.66/ghost). Visit this page in your browser and then follow the steps to complete admin account creation. You should be granted access to the administrative interface.

      6. To set up DNS for your app, create an A record for your domain which is assigned to the external IP for your app’s LoadBalancer. Review Linode’s DNS Manager guide for instructions.

      Upgrade your App

      The upgrade command can be used to upgrade an existing release to a new version of a chart, or just to supply new chart values:

      1. In your computer’s ghost-values.yaml file, add a line for the title of the website:

        ghost-values.yaml
        1
        2
        3
        4
        5
        6
        
        ghostHost: "ghost.example.com"
        ghostEmail: "[email protected]"
        ghostUsername: "admin"
        ghostPassword: "mySecurePassword123!!"
        mariadb.mariadbRootPassword: "secretpassword"
        ghostBlogTitle: "Example Site Name"
      2. Run the upgrade command, specifying the configuration file, release name, and chart name:

        helm upgrade --values=ghost-values.yaml ghost-1576075187 stable/ghost
        

      Roll Back a Release

      Upgrades (and even deletions) can be rolled back if something goes wrong:

      1. Run the helm ls command and observe the number under the “REVISION” column for your release:

          
        NAME            	NAMESPACE	REVISION	UPDATED                             	STATUS  	CHART      	APP VERSION
        ghost-1576075187	default  	2       	2019-12-11 11:54:49.136865 -0500 EST	deployed	ghost-9.0.3	3.1.1
        
        
      2. Every time you perform an upgrade, the revision count is incremented by 1 (and the counter starts at 1 when you first install a chart). So, your current revision number is 2. To roll back the upgrade you just performed, enter the previous revision number:

        helm rollback ghost-1576075187 1
        

      Delete a Release

      Caution

      By default, Helm 3 does not keep any information about deleted releases, which will prevent you from rolling back. If you suspect that you may need to rollback your release following deletion, you will need to use the --keep-history flag.
      1. Use the uninstall command with the name of a release to delete it:

        helm uninstall ghost-1576075187
        

        You should also confirm in the Linode Cloud Manager that the Volumes and NodeBalancer created for the app are removed as well.

        Note

        In Helm 2, deletions were performed using the delete command. This can still be entered to perform the same task, however in helm 3 delete aliases to uninstall.

      2. If you wish to keep a history of past releases, you will want to use the --keep-history flag. This is a change from Helm 2.

        helm uninstall --keep-history
        
      3. Helm will still save information about the uninstalled release. You can list releases including records where --keep-history was specified on uninstall:

        helm list --uninstalled
        

        Note

        You can no longer rollback a deleted or uninstalled release.

      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.

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



      Source link

      How To Install and Configure Postfix on Ubuntu 18.04


      Introdução

      O Postfix é um Agente de Transferência de E-mail (MTA) de código aberto popular que pode ser usado para rotear e entregar e-mails em um sistema Linux. Estima-se que cerca de 25% dos servidores públicos de e-mail na internet executem o Postfix.

      Neste guia, vamos ensinar como colocar o Postfix para funcionar rapidamente em um servidor Ubuntu 18.04.

      Pré-requisitos

      Para acompanhar este guia, será necessário ter acesso a um usuário não raiz com privilégios sudo. Você pode seguir nosso Guia de configuração inicial do servidor Ubuntu 18.04 para criar o usuário necessário.

      Para configurar corretamente o Postfix, será necessário um Nome de Domínio Completamente Qualificado (FQDN) apontando para seu servidor Ubuntu 18.04. É possível encontrar ajuda para configurar seu nome de domínio com o DigitalOcean seguindo este guia. Se quiser aceitar e-mails, será necessário garantir que você tenha também um registro MX apontando para seu servidor de e-mail.

      Para a finalidade deste tutorial, vamos considerar que você está configurando um host que tem o FQDN do mail.example.com.

      Passo 1 — Instalar o Postfix

      O Postfix está incluído nos repositórios padrão do Ubuntu, então a instalação é simples.

      Para começar, atualize o cache de pacotes local apt e, em seguida, instale o software. Vamos passar a variável de ambiente DEBIAN_PRIORITY=low para nosso comando de instalação para responder a alguns prompts adicionais:

      • sudo apt update
      • sudo DEBIAN_PRIORITY=low apt install postfix

      Use as informações a seguir para preencher os seus prompts corretamente para seu ambiente:

      • General type of mail configuration?: para isso, vamos escolher Internet Site, uma vez que isso corresponde às nossas necessidades de infraestrutura.
      • System mail name: este é o domínio base usado na construção de um endereço de e-mail válido quando apenas a parte da conta do endereço é fornecida. Por exemplo, o nome de host do nosso servidor é mail.example.com, mas provavelmente queremos definir o nome de e-mail do sistema para example.com, de maneira que, considerando o nome de usuário user1, o Postfix irá usar o endereço user1@example.com.
      • Root and postmaster mail recipient: esta é a conta Linux em que serão encaminhados e-mails destinados a root@ e postmaster@. Use sua conta principal para isso. No nosso caso, sammy.
      • Other destinations to accept mail for: define os destinos de e-mail que essa instância do Postfix aceitará. Se precisar adicionar quaisquer outros domínios que este servidor será responsável por receber, adicione-os aqui. Caso contrário, o padrão deve funcionar bem.
      • Force synchronous updates on mail queue?: uma vez que você provavelmente está usando um sistema de arquivos registrados em diário, aceite a opção *No *aqui.
      • Local networks: esta é uma lista das redes para as quais seu servidor de e-mail está configurado para retransmitir as mensagens. A rede padrão deve funcionar para a maioria dos cenários. Se escolher modificá-la, certifique-se de ser bastante restritivo em relação ao alcance da rede.
      • Mailbox size limit: isso pode ser usado para limitar o tamanho das mensagens. Definindo-o para “0” desativa qualquer restrição de tamanho.
      • Local address extension character: este é o caractere que pode ser usado para separar a parte regular do endereço de uma extensão (usado para criar pseudônimos dinâmicos).
      • Internet protocols to use: escolha se vai restringir a versão de IP que o Postfix suporta. Vamos escolher “all” para nossos fins.

      Para deixar bem claro, apresentamos a seguir as configurações que vamos usar neste guia:

      • General type of mail configuration?: Internet Site
      • System mail name: example.com (não mail.example.com)
      • Root and postmaster mail recipient: sammy
      • Other destinations to accept mail for: $myhostname, example.com, mail.example.com, localhost.example.com e localhost
      • Force synchronous updates on mail queue?: No
      • Local networks: 127.0.0.0/8[ ::ffff:127.0.0.0]/104[ ::1]/128
      • Mailbox size limit: 0
      • Local address extension character: +
      • Internet protocols to use: all

      Se, em algum momento, você precisar voltar para reajustar essas configurações, será possível fazer isso digitando:

      • sudo dpkg-reconfigure postfix

      Os prompts estarão pré-preenchidos com suas respostas anteriores.

      Quando tiver terminado, poderemos, então, fazer outras configurações para organizar nosso sistema como quisermos.

      Passo 2 — Ajustar a configuração do Postfix

      Em seguida, podemos ajustar algumas configurações sobre as quais o pacote não nos solicitou nada.

      Para começar, podemos definir a caixa de e-mail. Vamos usar o formato Maildir, que separa mensagens em arquivos individuais que depois são movidos entre os diretórios com base na ação do usuário. A outra opção é usar o formato** mbox** (que não vamos cobrir aqui) que armazena todas as mensagens em um único arquivo.

      Vamos definir a variável home_mailbox como Maildir/, o que criará uma estrutura de diretórios sob esse nome, dentro do diretório home do usuário. O comando postconf pode ser usado para consultar ou definir as configurações. Configure a home_mailbox digitando:

      • sudo postconf -e 'home_mailbox= Maildir/'

      Em seguida, podemos definir a localização da tabela virtual_alias_maps. Essa tabela mapeia contas de e-mail arbitrárias para contas do sistema Linux. Criaremos essa tabela em /etc/postfix/virtual. Mais uma vez, é possível usar o comando postconf:

      • sudo postconf -e 'virtual_alias_maps= hash:/etc/postfix/virtual'

      Passo 3 — Mapear endereços de email para as contas do Linux

      Em seguida, podemos configurar o arquivo de mapas virtuais. Abra o arquivo no seu editor de texto:

      • sudo nano /etc/postfix/virtual

      A tabela de mapa de pseudônimo virtual usa um formato muito simples. À esquerda, você pode listar quaisquer endereços para os quais deseja aceitar e-mails. Depois disso, separados por um espaço em branco, digite o usuário Linux para o qual gostaria que esse e-mail fosse entregue.

      Por exemplo, se quiser aceitar e-mails nos endereços contact@example.com e admin@example.com e que esses e-mails sejam entregues ao usuário Linux sammy, você pode configurar seu arquivo dessa forma:

      /etc/postfix/virtual

      contact@example.com sammy
      admin@example.com sammy
      

      Após mapear todos os endereços para as contas apropriadas do servidor, salve e feche o arquivo.

      Podemos aplicar o mapeamento digitando:

      • sudo postmap /etc/postfix/virtual

      Reinicie o processo do Postfix para ter certeza de que todas as alterações foram aplicadas:

      • sudo systemctl restart postfix

      Passo 4 — Ajustar o Firewall

      Se estiver executando o firewall UFW, como configurado no guia de configuração inicial do servidor, será necessário conceder uma exceção para o Postfix.

      É possível permitir conexões ao serviço digitando:

      O componente do servidor de correio eletrônico Postfix está instalado e pronto. Em seguida, vamos configurar um cliente que possa lidar com o e-mail que o Postfix irá processar.

      Passo 5 — Configurando o ambiente para corresponder à localização do e-mail

      Antes de instalar um cliente, devemos garantir que nossa variável de ambiente MAIL esteja configurada corretamente. O cliente irá inspecionar essa variável para descobrir onde procurar o e-mail do usuário.

      Para que a variável seja definida independentemente da forma como você acessa sua conta (através de ssh, su, su -, sudo, etc) será necessário definir a variável em alguns locais diferentes. Vamos adicioná-la a /etc/bash.bashrc e a um arquivo dentro de /etc/profile.d para garantir que cada usuário tenha essa variável configurada.

      Para adicionar a variável a esses arquivos, digite:

      • echo 'export MAIL=~/Maildir' | sudo tee -a /etc/bash.bashrc | sudo tee -a /etc/profile.d/mail.sh

      Para ler a variável na sua sessão atual, você pode obter o arquivo /etc/profile.d/mail.sh:

      • source /etc/profile.d/mail.sh

      Passo 6 — Instalar e configurar o cliente de e-mail

      Para interagir com o e-mail que está sendo entregue, vamos instalar o pacote s-nail. Esta é uma variante do cliente BSD xmail, que é rico em recursos, pode lidar com o formato Maildir corretamente e que, de maneira geral, é compatível com versões anteriores. A versão GNU do mail tem algumas limitações como, por exemplo, sempre salvar mensagens de leitura no formato mbox, independentemente do formato de origem.

      Para instalar o pacote s-nail, digite:

      Devemos ajustar algumas configurações. Abra o arquivo /etc/s-nail.rc no seu editor:

      Ao final do arquivo, adicione as seguintes opções:

      /etc/s-nail.rc

      . . .
      set emptystart
      set folder=Maildir
      set record=+sent
      

      Isso permitirá que o cliente abra, mesmo com uma caixa de entrada vazia. Isso também irá definir o diretório Maildir para a variável interna folder e, depois, usará essa variável para criarumarquivo mbox sent dentro dela para armazenar os e-mails enviados.

      Salve e feche o arquivo quando você terminar.

      Passo 7 — Inicializar o Maildir e testar o cliente

      Agora, podemos testar o cliente.

      Inicializando a estrutura do diretório

      A maneira mais fácil de criar a estrutura do Maildir dentro do nosso diretório home é enviando um e-mail para nós mesmos. Podemos fazer isso com o comando s-nail. Uma vez que o arquivo sent estará disponível apenas após a criação do Maildir, devemos desativar a gravação no arquivo em relação ao nosso e-mail inicial. Podemos fazer isso passando adicionando a opção -Snorecord.

      Envie o e-mail transmitindo uma string para o comando s-nail. Ajuste o comando para marcar seu usuário Linux como o destinatário:

      • echo 'init' | s-nail -s 'init' -Snorecord sammy

      Você pode obter a seguinte resposta:

      Output

      Can't canonicalize "/home/sammy/Maildir"

      Isso é normal e pode apenas aparecer ao enviar essa primeira mensagem. Podemos verificar e garantir que o diretório foi criado procurando nosso diretório ~/Maildir:

      Você deve ver que a estrutura do diretório foi criada e que um novo arquivo de mensagem está no diretório ~/Maildir/new:

      Output

      /home/sammy/Maildir/: cur new tmp /home/sammy/Maildir/cur: /home/sammy/Maildir/new: 1463177269.Vfd01I40e4dM691221.mail.example.com /home/sammy/Maildir/tmp:

      Parece que nosso e-mail foi entregue.

      Gerenciando o e-mail com o cliente

      Use o cliente para verificar seu e-mail:

      Você deve ver sua nova mensagem à espera:

      Output

      s-nail version v14.8.6. Type ? for help. "/home/sammy/Maildir": 1 message 1 new >N 1 sammy@example.com Wed Dec 31 19:00 14/369 init

      Apenas clicar no ENTER deve ser suficiente para mostrar sua mensagem:

      Output

      [-- Message 1 -- 14 lines, 369 bytes --]: From sammy@example.com Wed Dec 31 19:00:00 1969 Date: Fri, 13 May 2016 18:07:49 -0400 To: sammy@example.com Subject: init Message-Id: <20160513220749.A278F228D9@mail.example.com> From: sammy@example.com init

      Você pode voltar para sua lista de mensagens digitando h e, depois, pressionando a tecla ENTER:

      Output

      s-nail version v14.8.6. Type ? for help. "/home/sammy/Maildir": 1 message 1 new >R 1 sammy@example.com Wed Dec 31 19:00 14/369 init

      Uma vez que essa mensagem não é muito útil, podemos excluí-la digitando d e, em seguida, pressionando a tecla ENTER:

      Saia e volte para o terminal digitando q e, depois, pressionando a tecla ENTER:

      Enviando e-mails com o cliente

      É possível testar o envio de e-mails digitando uma mensagem em um editor de texto:

      Dentro, digite algum texto que você gostaria de enviar:

      ~/test_message

      Hello,
      
      This is a test.  Please confirm receipt!
      

      Ao usar o comando cat, podemos transmitir a mensagem para o processo s-nail. Isso irá enviar a mensagem como seu usuário Linux por padrão. Você pode ajustar o campo “De” com o sinalizador -r se quiser modificar esse valor para outra coisa:

      • cat ~/test_message | s-nail -s 'Test email subject line' -r from_field_account user@email.com

      As opções acima são:

      • -s: a linha de assunto do e-mail
      • -r: uma alteração opcional no campo “De:” do e-mail. Por padrão, o usuário Linux com o qual você estiver logado será usado para preencher este campo. A opção -r permite que você altere isso.
      • user@email.com: a conta para a qual enviar o e-mail. Substitua essa opção por uma conta válida à qual você tenha acesso.

      Você pode ver suas mensagens enviadas dentro do seu cliente s-nail. Inicie o cliente interativo novamente digitando:

      Depois disso, veja suas mensagens enviadas digitando:

      Você pode gerenciar os e-mails enviados usando os mesmos comandos que você usa para os e-mails recebidos.

      Conclusão

      Agora, você deve ter o Postfix configurado no seu servidor Ubuntu 18.04. O gerenciamento de servidores de e-mail pode ser uma tarefa difícil para administradores iniciantes, mas com esta configuração, você deverá ter as funcionalidades básicas de e-mails MTA para começar.



      Source link

      How to Install and Configure VNC on Debian 9


      Introdução

      O Virtual Network Computing, ou VNC, é um sistema de conexão que permite que você use seu teclado e mouse para interagir com um ambiente gráfico da área de trabalho em um servidor remoto. Isso facilita o gerenciamento de arquivos, software e configurações em um servidor remoto para os usuários que ainda não se sentem confortáveis com a linha de comando.

      Neste guia, você irá configurar um servidor VNC em um servidor Debian 9 e irá se conectar a ele de forma segura por um túnel SSH. Você usará o TightVNC, um pacote de controle remoto rápido e leve. Esta escolha irá garantir que nossa conexão VNC será suave e estável mesmo em conexões de Internet mais lentas.

      Pré-requisitos

      Para completar este tutorial, será necessário:

      • Um servidor Debian 9 configurado seguindo o guia de configuração inicial do servidor Debian 9, incluindo um usuário não raiz com acesso sudo e um firewall.
      • Um computador local com um cliente VNC instalado, compatível com conexões VNC sobre túneis SSH.

      Passo 1 — Instalando o Ambiente da Área de Trabalho e o Servidor VNC

      Por padrão, um servidor Debian 9 não vem com um ambiente gráfico de área de trabalho ou um servidor VNC instalado. Assim, vamos começar por instalar esses. Especificamente, iremos instalar os pacotes de ambiente de área de trabalho – Xfce – e do TightVNC mais recentes disponíveis no repositório oficial do Debian.

      No seu servidor, atualize sua lista de pacotes:

      Agora, instale o ambiente de área de trabalho Xfce no seu servidor:

      • sudo apt install xfce4 xfce4-goodies

      Durante a instalação, será solicitado que você selecione o layout do seu teclado a partir de uma lista de opções possíveis. Escolha o que for apropriado para o seu idioma e pressione Enter. A instalação continuará.

      Uma vez que a instalação tiver terminada, instale o servidor do TightVNC:

      • sudo apt install tightvncserver

      Para completar a configuração inicial do servidor VNC após a instalação, utilize o comando vncserver para configurar uma senha segura e crie os arquivos de configuração iniciais:

      Será solicitado que você digite e verifique uma senha para acessar sua máquina remotamente:

      Output

      You will require a password to access your desktops. Password: Verify:

      A senha deve ter entre seis e oito caracteres. Senhas com mais de 8 caracteres serão truncadas automaticamente.

      Uma vez verificada a senha, você terá a opção de criar uma senha somente para exibição. Usuários que fizerem login com a senha somente para exibição não poderão controlar a instância VNC com seus respectivos mouses ou teclados. Esta é uma opção útil se quiser demonstrar algo para outras pessoas utilizando seu servidor VNC, mas isso não é necessário.

      Depois, o processo criará os arquivos necessários de configuração padrão e informações de conexão para o servidor:

      Output

      Would you like to enter a view-only password (y/n)? n xauth: file /home/sammy/.Xauthority does not exist New 'X' desktop is your_hostname:1 Creating default startup script /home/sammy/.vnc/xstartup Starting applications specified in /home/sammy/.vnc/xstartup Log file is /home/sammy/.vnc/your_hostname:1.log

      Agora, vamos configurar o servidor VNC.

      Passo 2 — Configurando o Servidor VNC

      O servidor VNC precisa saber quais comandos executar quando ele iniciar. Especificamente, o VNC precisa saber a qual ambiente gráfico de área de trabalho ele deve se conectar.

      Estes comandos estão localizados em um arquivo de configuração chamado de xstartup na pasta .vnc sob o seu diretório inicial. O script de inicialização foi criado quando você executou o vncserver no passo anterior, mas vamos criar o nosso próprio script para iniciar a área de tabalho Xfce.

      Quando o VNC é configurado pela primeira vez, ele inicia uma instância de servidor padrão na porta 5901. Essa porta é chamada de porta de exibição e é referida pelo VNC como :1. O VNC pode iniciar várias instâncias em outras porta de exibição, como :2, :3 e assim por diante.

      Uma vez que vamos alterar a configuração do servidor VNC, primeiramente, interrompa a instância do servidor VNC que estiver em execução na porta 5901 com o seguinte comando:

      O resultado deve se parecer com este, embora você veja um PID diferente:

      Output

      Killing Xtightvnc process ID 17648

      Antes de modificar o arquivo xstartup, faça um back-up do original:

      • mv ~/.vnc/xstartup ~/.vnc/xstartup.bak

      Agora, crie um novo arquivo de xstartup e abra ele no seu editor de texto:

      Os comandos neste arquivo são executados de maneira automática, sempre que você iniciar ou reiniciar o servidor VNC. Precisamos que o VNC inicie nosso ambiente de área de trabalho, caso ainda não tiver sido iniciado. Adicione esses comandos ao arquivo:

      ~/.vnc/xstartup

      #!/bin/bash xrdb $HOME/.Xresources startxfce4 &

      O primeiro comando no arquivo, xrdb $HOME/ .Xresources, diz ao framework GUI do VNC para ler o usuário do servidor .Xresources arquivo. O .Xresources é onde um usuário pode fazer alterações em certas configurações do ambiente de trabalho gráfico, como as cores de terminal, temas de cursor e rendering de fontes. O segundo comando diz ao servidor para iniciar o Xfce, que é onde você encontrará todos os software gráficos necessários para gerenciar confortavelmente seu servidor.

      Para garantir que o servidor VNC será capaz de usar esse novo arquivo de inicialização corretamente, precisaremos torná-lo executável.

      • sudo chmod +x ~/.vnc/xstartup

      Agora, reinicie o servidor VNC.

      Você verá um resultado semelhante a este:

      Output

      New 'X' desktop is your_hostname:1 Starting applications specified in /home/sammy/.vnc/xstartup Log file is /home/sammy/.vnc/your_hostname:1.log

      Com a configuração implementada, vamos conectar nossa máquina local ao servidor.

      O VNC propriamente dito não utiliza protocolos de segurança ao se conectar. Utilizaremos um túnel SSH para conectar ao nosso servidor com segurança. Em seguida, diremos ao nosso cliente VNC para usar aquele túnel e não fazer uma conexão direta.

      Crie uma conexão SSH no seu computador local; ela encaminhará a conexão localhost para o VNC. É possível fazer isto através do terminal no Linux ou no macOS com o seguinte comando:

      • ssh -L 5901:127.0.0.1:5901 -C -N -l sammy your_server_ip

      O switch -L especifica as ligações de porta. Neste caso, estamos ligando a porta 5901 da conexão remota à porta 5901 de sua máquina local. O switch -C habilita a compressão, enquanto o switch -N diz ao ssh que não queremos executar um comando remoto. O switch -l especifica o nome de login remoto.

      Lembre-se de substituir o sammy e o your_server_ip pelo nome de usuário não raiz do comando sudo e o endereço de IP do seu servidor.

      Se estiver usando um cliente SSH gráfico, como o PuTTY, utilize o your_server_ip como o IP de conexão e defina o localhost:5901 como uma nova porta redirecionada nas configurações de túnel SSH do programa.

      Assim que o túnel estiver em execução, utilize um cliente VNC para se conectar ao localhost:5901. Será solicitado que autentique usando a senha definida no Passo 1.

      Uma vez que estiver conectado, verá o área de trabalho padrão Xfce.

      Conexão remota VNC com o servidor Debian 9 Selecione a opção Usar configuração padrão para configurar sua área de trabalho rapidamente.

      É possível acessar arquivos em seu diretório inicial com o gerenciador de arquivos ou da linha de comando, como visto aqui:

      Arquivos através de conexão VNC com o Debian 9

      Na máquina local, pressione CTRL+C no terminal para parar o túnel SSH e voltar ao seu prompt. Isto também irá desconectar sua sessão VNC.

      A seguir, vamos configurar o servidor de VNC como um serviço.

      Passo 4 — Executando o VNC como um Serviço de Sistema

      Depois, vamos configurar o servidor VNC como um serviço de systemd para que possamos iniciar, parar e reiniciar se necessário, como em qualquer outro serviço. Isso também irá garantir que o VNC inicie quando seu servidor reinicializar.

      Primeiramente, crie um novo arquivo de unidade chamado /etc/systemd/system/vncserver@.service, usando seu editor de texto favorito:

      • sudo nano /etc/systemd/system/vncserver@.service

      O símbolo @ no final do nome permitirá que enviemos um argumento que poderemos usar na configuração do serviço. Vamos usar isso para especificar a porta de exibição do VNC que queremos usar quando gerenciarmos o serviço.

      Adicione as linhas a seguir ao arquivo. Certifique-se de alterar o valor do User, Group, WorkingDirectory e o nome de usuário no valor do PIDFILE para corresponder ao seu nome de usuário:

      /etc/systemd/system/vncserver@.service

      [Unit] Description=Start TightVNC server at startup After=syslog.target network.target [Service] Type=forking User=sammy Group=sammy WorkingDirectory=/home/sammy PIDFile=/home/sammy/.vnc/%H:%i.pid ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1 ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :%i ExecStop=/usr/bin/vncserver -kill :%i [Install] WantedBy=multi-user.target

      O comando ExecStartPre interrompe o VNC , se ele já estiver em execução. O comando ExecStart inicia o VNC e define a profundidade de cor para 24 bits com uma resolução de 1280x800. Também é possível modificar essas opções de inicialização para atender suas necessidades.

      Salve e feche o arquivo.

      A seguir, faça com que o sistema saiba do novo arquivo de unidade.

      • sudo systemctl daemon-reload

      Habilite o arquivo de unidade.

      • sudo systemctl enable vncserver@1.service

      O 1 que depois do símbolo @ significa sobre qual número de exibição o serviço deve aparecer, neste caso, o padrão :1, como foi discutido no Passo 2.

      Interrompa a instância atual do servidor VNC se ele ainda estiver em execução.

      Então, inicie-o como você iniciaria qualquer outro serviço systemd.

      • sudo systemctl start vncserver@1

      É possível verificar se ele iniciou com este comando:

      • sudo systemctl status vncserver@1

      Se ele iniciou corretamente, a saída deverá se parecer com isto:

      Output

      ● vncserver@1.service - Start TightVNC server at startup Loaded: loaded (/etc/systemd/system/vncserver@.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2018-09-05 16:47:40 UTC; 3s ago Process: 4977 ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :1 (code=exited, status=0/SUCCESS) Process: 4971 ExecStartPre=/usr/bin/vncserver -kill :1 > /dev/null 2>&1 (code=exited, status=0/SUCCESS) Main PID: 4987 (Xtightvnc) ...

      Seu servidor VNC agora estará disponível quando reiniciar a máquina.

      Inicie seu túnel SSH novamente:

      • ssh -L 5901:127.0.0.1:5901 -C -N -l sammy your_server_ip

      Então, faça uma nova conexão usando seu software de cliente VNC com o localhost:5901 para conectar à sua máquina.

      Conclusão

      Agora, você tem um servidor de VNC seguro em execução no seu servidor Debian 9. Agora, poderá gerenciar seus arquivos, software e configurações com uma interface gráfica conhecida e fácil de usar e será capaz de executar software gráficos como navegadores de Web remotamente.



      Source link