diff --git a/ci/vale/dictionary.txt b/ci/vale/dictionary.txt index 6335bb1b937..5f95f13d8e2 100644 --- a/ci/vale/dictionary.txt +++ b/ci/vale/dictionary.txt @@ -1332,6 +1332,7 @@ toolchain toolchains traceroute trackbar +transcode transcoder transcoding trello diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/Use_Puppet_Modules_to_Create_a_LAMP_Stack_smg.jpg b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/Use_Puppet_Modules_to_Create_a_LAMP_Stack_smg.jpg new file mode 100644 index 00000000000..4af9bfed51e Binary files /dev/null and b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/Use_Puppet_Modules_to_Create_a_LAMP_Stack_smg.jpg differ diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md new file mode 100644 index 00000000000..3e9a2542bd5 --- /dev/null +++ b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/index.md @@ -0,0 +1,555 @@ +--- +author: + name: Linode +description: 'Learn how to efficiently use Puppet modules to manage files and services, create templates, and store data in Hiera in this simple tutorial.' +keywords: ["puppet", "automation", "lamp", "configuration management"] +license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)' +aliases: ['applications/puppet/create-puppet-module/','applications/configuration-management/create-puppet-module/'] +modified: 2019-01-25 +modified_by: + name: Linode +published: 2015-01-25 +title: Use Puppet Modules to Create a LAMP Stack +--- + +![Use Puppet Modules to Create a LAMP Stack](Use_Puppet_Modules_to_Create_a_LAMP_Stack_smg.jpg) + +Puppet modules are the building blocks of your Puppet managed servers. Modules install and configure packages, create directories, and generate any other server changes that the user includes in the module. A Puppet module aims to perform all parts of a certain task, such as downloading the Apache package, configuring all files, changing the MPM data, and setting up virtual hosts. Modules are, in turn, broken down into classes that are `.pp` files meant to simplify the module into various tasks and improve the module's readability for any future users. + +In this guide, you will create an Apache and a PHP module. A MySQL module will be adapted from the Puppet Lab's MySQL module found on the [Puppet Forge](https://forge.puppet.com/). These steps will create a full LAMP stack on your server and provide an overview of the various ways modules can be utilized. + +## Before You Begin + +Set up a Puppet Master (Ubuntu 18.04) and two Puppet agents (Ubuntu 18.04 and CentOS 7) by following the steps in the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup) guide. + +## Create the Apache Module + +1. From the Puppet Master, navigate to Puppet's module directory and create the `apache` directory: + + cd /etc/puppetlabs/code/environments/production/modules/ + sudo mkdir apache + +1. From within the `apache` directory, create `manifests`, `templates`, `files`, and `examples` directories: + + cd apache + sudo mkdir {manifests,templates,files,examples} + +1. Navigate to the `manifests` directory: + + cd manifests + + From here, the module will be separated into classes, based on the goals of that particular section of code. In this instance, there will be an `init.pp` class for downloading the Apache package, a `params.pp` file to define any variables and parameters, `config.pp` to manage any configuration files for the Apache service itself, and a `vhosts.pp` file to define the virtual hosts. This module will also make use of [Hiera](http://docs.puppetlabs.com/hiera/latest/) data to store variables for each node. + +### Create the Initial Apache Class and Parameters + +1. From within the `manifests` directory, create an `init.pp` file to hold the `apache` class. This class should share its name with the module name. This file will be used to install the Apache package. Since Ubuntu 18.04 and CentOS 7 use different package names for Apache, a variable will be used: + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} +class apache { + + package { 'apache': + name => $apachename, + ensure => present, + } + +} + +{{< /file >}} + + + The `package` resource allows for the management of a package. This is used to add, remove, or ensure a package is present. In most cases, the name of the resource (`apache`, above) should be the name of the package being managed. Because of the difference in naming conventions, however, this resource is simply called `apache`, while the actual *name* of the package is called upon with the `name` reference. `name`, in this instance, calls for the yet-undefined variable `$apachename`. The `ensure` reference ensures that the package is `present`. + +1. The `params.pp` file will be used to define the needed variables. While these variables could be defined within the `init.pp` file, since more variables will need to be used outside of the resource type itself, using a `params.pp` file allows for variables to be defined in `if` statements and used across multiple classes. + + Create a `params.pp` and add the following code: + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp" puppet >}} +class apache::params { + + if $::osfamily == 'RedHat' { + $apachename = 'httpd' + } + elsif $::osfamily == 'Debian' { + $apachename = 'apache2' + } + else { + fail ( 'this is not a supported distro.') + } + +} + +{{< /file >}} + + Outside of the original `init.pp` class, each class name needs to branch off of `apache`. As such, this class is called `apache::params`. The name after the double colon should share a name with the file. + + An `if` statement is used to define the parameters, pulling from information provided by [Facter](https://puppetlabs.com/facter), which is already installed on the Puppet master. In this case, Facter will be used to pull down the operating system family (`osfamily`), to discern if it is Red Hat or Debian-based. + + {{< note >}} +For the duration of this guide, when something needs to be added to the parameter list the variables needed for Red Hat and Debian will be provided, but the expanding code will not be shown. A complete copy of `params.pp` can be viewed [here](/docs/assets/params.pp). +{{< /note >}} + +1. With the parameters finally defined, we need to call the `params.pp` file and the parameters into `init.pp`. To do this, the parameters need to be added after the class name, but before the opening curly bracket (`{`): + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} +class apache ( + $apachename = $::apache::params::apachename, +) inherits ::apache::params { + +{{< /file >}} + + + The value string `$::apache::params::value` tells Puppet to pull the values from the `apache` modules, `params` class, followed by the parameter name. The fragment `inherits ::apache::params` allows for `init.pp` to inherit these values. + + +### Manage Configuration Files + +The Apache configuration file will be different depending on whether you are working on a Red Hat- or Debian-based system. These can be viewed here: [httpd.conf (Red Hat)](/docs/assets/httpd.conf), [apache2.conf (Debian)](/docs/assets/apache2.conf). + +1. Copy the content of `httpd.conf` and `apache2.conf` in separate files and save them in the `files` directory located at `/etc/puppetlabs/code/environments/production/modules/apache/files`. + +1. Both files need to be edited to disable keepalive. You will need to add the line `KeepAlive Off` the `httpd.conf` file. If you do not want to change this setting, a comment should be added to the top of each file: + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/files/httpd.conf" aconf >}} +# This file is managed by Puppet + +{{< /file >}} + + +1. Add these files to the `init.pp` file, so Puppet will know where they are located on both the master server and agent nodes. To do this, the `file` resource is used: + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} +file { 'configuration-file': + path => $conffile, + ensure => file, + source => $confsource, +} + +{{< /file >}} + + + Because the configuration file is found in two different locations, the resource is given the generic name `configuration-file` with the file path defined as a parameter with the `path` attribute. `ensure` ensures that it is a file. `source` provides the location on the Puppet master of the files created above. + +1. Open the `params.pp` file. The `$conffile` and `$confsource` variables need to be defined within the `if` statement: + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp" puppet >}} +if $::osfamily == 'RedHat' { + +... + + $conffile = '/etc/httpd/conf/httpd.conf' + $confsource = 'puppet:///modules/apache/httpd.conf' +} +elsif $::osfamily == 'Debian' { + +... + + $conffile = '/etc/apache2/apache2.conf' + $confsource = 'puppet:///modules/apache/apache2.conf' +} +else { + +... +{{< /file >}} + + + These parameters will also need to be added to the beginning of the `apache` class declaration in the `init.pp` file, similar to the previous example. A complete copy of the `init.pp` file can be seen [here](/docs/assets/puppet_apacheinit.pp) for reference. + +1. When the configuration file is changed, Apache needs to restart. To automate this, the `service` resource can be used in combination with the `notify` attribute, which will call the resource to run whenever the configuration file is changed: + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp" puppet >}} +file { 'configuration-file': + path => $conffile, + ensure => file, + source => $confsource, + notify => Service['apache-service'], +} + +service { 'apache-service': + name => $apachename, + hasrestart => true, +} + +{{< /file >}} + + + The `service` resource uses the already-created parameter that defined the Apache name on Red Hat and Debian systems. The `hasrestart` attribute will trigger a restart of the defined service. + + +### Create the Virtual Hosts Files + +Depending on your systems distribution the virtual hosts files will be managed differently. Because of this, the code for virtual hosts will be encased in an `if` statement, similar to the one used in the `params.pp` class but containing actual Puppet resources. This will provide an example of an alternate use of `if` statements within Puppet's code. + +1. From within the `apache/manifests/` directory, create and open a `vhosts.pp` file. Add the skeleton of the `if` statement: + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp" puppet >}} +class apache::vhosts { + + if $::osfamily == 'RedHat' { + + } elsif $::osfamily == 'Debian' { + + } else { + + } + +} + +{{< /file >}} + + +1. The location of the virtual hosts file on our CentOS 7 server is `/etc/httpd/conf.d/vhost.conf`. This file will need to be created as a template on the Puppet master. The same needs to be done for the Ubuntu virtual hosts file, which is located at `/etc/apache2/sites-available/example.com.conf`, replacing `example.com` with the server's FQDN. Navigate to the `templates` file within the `apache` module, and then create two files for your virtual hosts: + + For Red Hat systems: + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/templates/vhosts-rh.conf.erb" aconf >}} + + ServerAdmin <%= @adminemail %> + ServerName <%= @servername %> + ServerAlias www.<%= @servername %> + DocumentRoot /var/www/<%= @servername -%>/public_html/ + ErrorLog /var/www/<%- @servername -%>/logs/error.log + CustomLog /var/www/<%= @servername -%>/logs/access.log combined + + +{{< /file >}} + + + For Debian systems: + + {{< file "/etc/puppet/modules/apache/templates/vhosts-deb.conf.erb" aconf >}} + + ServerAdmin <%= @adminemail %> + ServerName <%= @servername %> + ServerAlias www.<%= @servername %> + DocumentRoot /var/www/html/<%= @servername -%>/public_html/ + ErrorLog /var/www/html/<%- @servername -%>/logs/error.log + CustomLog /var/www/html/<%= @servername -%>/logs/access.log combined + /public_html> + Require all granted + + + +{{< /file >}} + + + Only two variables are used in these files: `adminemail` and `servername`. These will be defined on a node-by-node basis, within the `site.pp` file. + +1. Return to the `vhosts.pp` file. The templates created can now be referenced in the code: + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp" puppet >}} +class apache::vhosts { + + if $::osfamily == 'RedHat' { + file { '/etc/httpd/conf.d/vhost.conf': + ensure => file, + content => template('apache/vhosts-rh.conf.erb'), + } + } elsif $::osfamily == 'Debian' { + file { "/etc/apache2/sites-available/$servername.conf": + ensure => file, + content => template('apache/vhosts-deb.conf.erb'), + } + } else { + fail('This is not a supported distro.') + } + +} + +{{< /file >}} + + + Both distribution families call to the `file` resource and take on the title of the virtual host's location on the respective distribution. For Debian, this once more means referencing the `$servername` value. The `content` attribute calls to the respective templates. + + {{< note >}} +Values containing variables, such as the name of the Debian file resource above, need to be wrapped in double quotes (`"`). Any variables in single quotes (`'`) are parsed exactly as written and will not pull in a variable. +{{< /note >}} + +1. Both virtual hosts files reference two directories that are not on the systems by default. These can be created through the use of the `file` resource, each located within the `if` statement. The complete `vhosts.conf` file should resemble: + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp" puppet >}} +class apache::vhosts { + + if $::osfamily == 'RedHat' { + file { '/etc/httpd/conf.d/vhost.conf': + ensure => file, + content => template('apache/vhosts-rh.conf.erb'), + } + file { [ '/var/www/$servername', + '/var/www/$servername/public_html', + '/var/www/$servername/log', ]: + ensure => directory, + } + } elsif $::osfamily == 'Debian' { + file { "/etc/apache2/sites-available/$servername.conf": + ensure => file, + content => template('apache/vhosts-deb.conf.erb'), + } + file { [ '/var/www/$servername', + '/var/www/$servername/public_html', + '/var/www/$servername/logs', ]: + ensure => directory, + } + } else { + fail ( 'This is not a supported distro.') + } + +} + +{{< /file >}} + + + +### Test and Run the Module + +1. From within the `apache/manifests/` directory, run the `puppet parser` on all files to ensure the Puppet coding is without error: + + sudo /opt/puppetlabs/bin/puppet parser validate init.pp params.pp vhosts.pp + + It should return empty, barring any issues. + +1. Navigate to the `examples` directory within the `apache` module. Create an `init.pp` file and include the created classes. Replace the values for `$servername` and `$adminemail` with your own: + + {{< file "/etc/puppetlabs/code/environments/production/modules/apache/examples/init.pp" puppet >}} +$serveremail = 'webmaster@example.com' +$servername = 'example.com' + +include apache +include apache::vhosts + +{{< /file >}} + + +1. Test the module by running `puppet apply` with the `--noop` tag: + + sudo /opt/puppetlabs/bin/puppet apply --noop init.pp + + It should return no errors, and output that it will trigger refreshes from events. To install and configure apache on the Puppet master, this can be run again without `--noop` , if so desired. + +1. Navigate back to the main Puppet directory and then to the `manifests` folder (**not** the one located in the Apache module). + + cd /etc/puppetlabs/code/environments/production/manifests + + If you are continuing this guide from the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, you should have a `site.pp` file already created. If not, create one now. + +1. Open `site.pp` and include the Apache module for each agent node. Also input the variables for the `adminemail` and `servername` parameters. If you followed the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, a single node configuration within `site.pp` will resemble the following: + + {{< file "/etc/puppetlabs/code/environments/production/manifests/site.pp" puppet >}} +node 'ubuntuhost.example.com' { + $adminemail = 'webmaster@example.com' + $servername = 'hostname.example.com' + + include accounts + include apache + include apache::vhosts + + resources { 'firewall': + purge => true, + } + + Firewall { + before => Class['firewall::post'], + require => Class['firewall::pre'], + } + + class { ['firewall::pre', 'firewall::post']: } + + } + +node 'centoshost.example.com' { + $adminemail = 'webmaster@example.com' + $servername = 'hostname.example.com' + + include accounts + include apache + include apache::vhosts + + resources { 'firewall': + purge => true, + } + + Firewall { + before => Class['firewall::post'], + require => Class['firewall::pre'], + } + + class { ['firewall::pre', 'firewall::post']: } + + } + + {{< /file >}} + + If you did not follow the [Getting Started with Puppet - Basic Installation and Setup](/docs/applications/configuration-management/getting-started-with-puppet-6-1-basic-installation-and-setup/) guide, then your `site.pp` file should resemble the following example: + + {{< file "/etc/puppetlabs/code/environments/production/manifests/site.pp" puppet >}} +node 'ubupuppet.members.linode.com' { + $adminemail = 'webmaster@example.com' + $servername = 'hostname.example.com' + + include apache + include apache::vhosts + + } + +node 'centospuppet.members.linode.com' { + $adminemail = 'webmaster@example.com' + $servername = 'hostname.example.com' + + include apache + include apache::vhosts + + } + {{}} + + +1. By default, the Puppet agent service on your managed nodes will automatically check with the master once every 30 minutes and apply any new configurations from the master. You can also manually invoke the Puppet agent process in-between automatic agent runs. To manually run the new module on your agent nodes, log in to the nodes and run: + + sudo /opt/puppetlabs/bin/puppet agent -t + + +## Using the MySQL Module + +Many modules needed to run a server already exist within Puppet Labs' [Puppet Forge](https://forge.puppetlabs.com). These can be configured just as extensively as a module that you created and can save time since the module need not be created from scratch. + +Ensure you are in the `/etc/puppetlabs/code/environments/production/modules` directory and install the [Puppet Forge's MySQL module](https://forge.puppetlabs.com/puppetlabs/mysql) by PuppetLabs. This will also install any prerequisite modules. + + cd /etc/puppetlabs/code/environments/production/modules + sudo /opt/puppetlabs/bin/puppet module install puppetlabs-mysql + +### Use Hiera to Create Databases + +Before you begin to create the configuration files for the MySQL module, consider that you may not want the same values to be used across all agent nodes. To supply Puppet with the correct data per node, Hiera is used. In this instance, you will be using a different root password per node, thus creating different MySQL databases. + +1. Navigate to `/etc/puppet` and create Hiera's configuration file `hiera.yaml` in the main `puppet` directory. You will use Hiera's default values: + + {{< file "/etc/puppetlabs/code/environments/production/hiera.yaml" yaml >}} +--- +version: 5 +hierarchy: + - name: Common + path: common.yaml +defaults: + data_hash: yaml_data + datadir: data + +{{< /file >}} + + +1. Create the file `common.yaml`. It will be used to define the default `root` password for MySQL: + + {{< file "/etc/puppetlabs/code/environments/production/common.yaml" yaml >}} +mysql::server::root_password: 'password' + +{{< /file >}} + + + The `common.yaml` file is used when a variable is not defined elsewhere. This means all servers will share the same MySQL root password. These passwords can also be hashed to increase security. + +1. To use the MySQL module's defaults you can simply add an `include '::mysql::server'` line to the `site.pp` file. However, in this example, you will override some of the module's defaults to create a database for each of your nodes. Edit the `site.pp` file with the following values: + + {{< file >}} +node 'ubupuppet.members.linode.com' { + $adminemail = 'webmaster@example.com' + $servername = 'hostname.example.com' + + include apache + include apache::vhosts + include php + + mysql::db { "mydb_${fqdn}": + user => 'myuser', + password => 'mypass', + dbname => 'mydb', + host => $::fqdn, + grant => ['SELECT', 'UPDATE'], + tag => $domain, + } + +} + +node 'centospuppet.members.linode.com' { + $adminemail = 'webmaster@example.com' + $servername = 'hostname.example.com' + + include apache + include apache::vhosts + include mysql::server + include php + + mysql::db { "mydb_${fqdn}": + user => 'myuser', + password => 'mypass', + dbname => 'mydb', + host => $::fqdn, + grant => ['SELECT', 'UPDATE'], + tag => $domain, + } + + } + {{}} + +1. You can run these updates manually on each node by SSHing into each node and issuing the following command: + + sudo /opt/puppetlabs/bin/puppet agent -t + + Otherwise, the Puppet agent service on your managed nodes will automatically check with the master once every 30 minutes and apply any new configurations from the master. + + +## Create the PHP Module + +1. Create the `php` directory in the `/etc/puppetlabs/code/environments/production/modules` path, and generate the `files`, `manifests`, `templates`, and `examples` directories afterward: + + sudo mkdir php + cd php + sudo mkdir {files,manifests,examples,templates} + +1. Create the `init.pp`. This file will use the `package` resource to install PHP. Two packages will be installed: The PHP package and the PHP extension and application repository. Add the following contents to your file: + + {{< file "/etc/puppetlabs/code/environments/production/modules/php/manifests/init.pp" puppet >}} +class php { + + package { 'php': + name: $phpname, + ensure: present, + } + + package { 'php-pear': + ensure: present, + } + +} + +{{< /file >}} + +1. Add `include php` to the hosts in your `sites.pp` file: + + {{< file "/etc/puppetlabs/code/environments/production/manifests/site.pp" puppet >}} + node 'ubupuppet.members.linode.com' { + $adminemail = 'webmaster@example.com' + $servername = 'hostname.example.com' + + include apache + include apache::vhosts + include mysql::database + include php + + } + + node 'centospuppet.members.linode.com' { + $adminemail = 'webmaster@example.com' + $servername = 'hostname.example.com' + + include apache + include apache::vhosts + include mysql::database + include php + + } + {{}} + +1. Run the following command on your agent nodes to pull in any changes to your servers. + + sudo /opt/puppetlabs/bin/puppet agent -t + + Otherwise, the Puppet agent service on your managed nodes will automatically check with the master once every 30 minutes and apply any new configurations from the master. + + You should now have a fully functioning LAMP stack on each of your Puppet managed nodes. \ No newline at end of file diff --git a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack/index.md b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack/index.md index 9132a4d6f9e..444cc8de381 100644 --- a/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack/index.md +++ b/docs/applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack/index.md @@ -6,6 +6,8 @@ description: 'Learn how to efficiently use Puppet modules to manage files and se keywords: ["puppet", "automation", "puppet master", "puppet agent", "modules", "server automation", "configuration management"] license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)' aliases: ['applications/puppet/create-puppet-module/','applications/configuration-management/create-puppet-module/'] +deprecated: true +deprecated_link: 'applications/configuration-management/use-puppet-modules-to-create-a-lamp-stack-ubuntu-18-04-master/' modified: 2015-11-12 modified_by: name: Elle Krout @@ -608,4 +610,4 @@ class php { {{< /file >}} -5. Add `include php` to the hosts in your `sites.pp` file and run `puppet agent -t` on your agent nodes to pull in any changes to your servers. +5. Add `include php` to the hosts in your `sites.pp` file and run `puppet agent -t` on your agent nodes to pull in any changes to your servers. \ No newline at end of file diff --git a/docs/email/postfix/email-with-postfix-dovecot-and-mariadb-on-centos-7/index.md b/docs/email/postfix/email-with-postfix-dovecot-and-mariadb-on-centos-7/index.md index 2e45b9083da..e827ca72c9a 100644 --- a/docs/email/postfix/email-with-postfix-dovecot-and-mariadb-on-centos-7/index.md +++ b/docs/email/postfix/email-with-postfix-dovecot-and-mariadb-on-centos-7/index.md @@ -604,7 +604,7 @@ service lmtp { Locate `service auth` and configure it as shown below: - {{< file "etc/dovecot/conf.d/10-master.conf" >}} + {{< file "/etc/dovecot/conf.d/10-master.conf" >}} ... service auth { ... @@ -628,7 +628,7 @@ service auth { In the `service auth-worker` section, uncomment the `user` line and set it to `vmail`: - {{< file "1etc/dovecot/conf.d/10-master.conf" >}} + {{< file "/etc/dovecot/conf.d/10-master.conf" >}} ... service auth-worker { ... diff --git a/docs/email/postfix/email-with-postfix-dovecot-and-mysql/index.md b/docs/email/postfix/email-with-postfix-dovecot-and-mysql/index.md index e2a9e4d89cb..25eba639633 100644 --- a/docs/email/postfix/email-with-postfix-dovecot-and-mysql/index.md +++ b/docs/email/postfix/email-with-postfix-dovecot-and-mysql/index.md @@ -521,7 +521,7 @@ postmaster_address=postmaster at example.com {{< file "10-mail.conf" >}} ... -mail_location = maildir:/var/mail/vhosts/%d/%n +mail_location = maildir:/var/mail/vhosts/%d/%n/ ... mail_privileged_group = mail ... diff --git a/docs/platform/manager/using-the-linode-shell-lish/index.md b/docs/platform/manager/using-the-linode-shell-lish/index.md index eb85100e335..1bc4872f5e5 100644 --- a/docs/platform/manager/using-the-linode-shell-lish/index.md +++ b/docs/platform/manager/using-the-linode-shell-lish/index.md @@ -6,7 +6,7 @@ description: 'Learn how to use Lish as a shell for managing or rescuing your Lin keywords: ["Console", "Shell", "Lish", "rescue"] license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)' aliases: ['using-lish-the-linode-shell/','troubleshooting/using-lish-the-linode-shell/','networking/using-the-linode-shell-lish/','platform/using-the-linode-shell-lish/'] -modified: 2018-09-17 +modified: 2019-02-07 modified_by: name: Linode published: 2009-08-04 @@ -166,75 +166,69 @@ This command format works for all Lish functionality. ## Lish Gateway Fingerprints -The valid fingerprints for the Lish gateway boxes are as follows: +The valid fingerprints for the Lish gateway boxes in our data centers are as follows: ### Atlanta - -These are the fingerprints for the Lish gateway in our Atlanta data center (lish-atlanta.linode.com): +lish-atlanta.linode.com RSA 59:30:1a:0b:93:5e:3f:4b:6f:d1:96:ff:7e:9e:12:f8 DSA 0b:90:ed:f2:a1:e0:55:5b:38:6e:5d:6e:fa:00:63:7f ECDSA SHA256 9V/AK2EcQFjYzm1PU3XhOJbzhwYCoqqThl2vnFxbyvg ### Dallas - -These are the fingerprints for the Lish gateway in our Dallas data center (lish-dallas.linode.com): +lish-dallas.linode.com RSA 6d:3d:b5:d0:42:1c:49:45:a6:47:29:bd:88:4e:58:d4 DSA 58:bc:07:fa:c1:61:a4:3b:b5:00:3b:9b:6b:78:c6:c5 ECDSA SHA256 IVXyNAH78L7KJFgfrScp948+56BTew8Z41nOkAw2kGo -### Frankfurt + RSA SHA256:kY9nTDp2xAG1HQPRfDKYUR8t6ldd51RTTDsFDDMsDT + ECDSA SHA256:NP/vuIdkObvvZWApVA93OOuUqRBz6PeDrvMfg9kglxA -These are the fingerprints for the Lish gateway in our Frankfurt data center (lish-frankfurt.linode.com): +### Frankfurt +lish-frankfurt.linode.com RSA 43:76:22:43:0e:01:cb:84:6a:80:b9:9b:90:34:c7:b1 DSA 87:2d:c9:5a:76:06:e6:3d:08:70:1b:2e:a6:b4:e8:c2 ECDSA SHA256 4F/M6SYqrukVHJJbCkzw4tw4TjRVfAY98cDKwqXT9MY ### Fremont - -These are the fingerprints for the Lish gateway in our Fremont data center (lish-fremont.linode.com): +lish-fremont.linode.com RSA 2c:43:0e:fc:88:f2:3a:dd:01:43:3a:fc:9f:67:9f:66 DSA 19:30:1a:48:85:aa:78:ab:46:8d:0f:4d:00:88:e6:b7 ECDSA SHA256 0BmmvUv/itqa1ruA4KmqzMFaY4Ijdw/YW+SoiMJT1mo ### London - -These are the fingerprints for the Lish gateway in our London data center (lish-london.linode.com): +lish-london.linode.com RSA 71:27:30:cd:dc:69:7a:fe:58:4a:04:e6:6b:5f:b4:e2 DSA ce:41:c0:48:2c:93:de:c8:d2:a9:bf:3f:97:1f:04:ad ECDSA SHA256 L7sQgnpnoBwRoyIYXAFBs8SdSnwtyYmhXs1p/mQDKQM ### Newark - -These are the fingerprints for the Lish gateway in our Newark data center (lish-newark.linode.com): +lish-newark.linode.com RSA 11:2a:57:a4:f8:ca:42:b2:c0:ab:17:58:0d:0c:b7:8b DSA a1:e2:f5:5a:71:f9:b8:98:d9:a6:4c:65:e5:05:ea:04 ECDSA SHA256 p+fsr503gCnyZhAG7wx5mzrvw9MIPdgzvKauScUm8wk ### Singapore - -These are the fingerprints for the Lish gateway in our Singapore data center (lish-singapore.linode.com): +lish-singapore.linode.com RSA 06:26:d8:2a:12:8b:2f:d7:6c:54:72:5a:a7:7b:da:7b DSA 0c:f9:f9:d6:f3:0a:f6:bb:82:82:07:4b:51:db:e2:35 ECDSA SHA256 LzlyP1Uj1nne2KwCkB5HlOWoHLH/7YrApZlNCn5204A ### Tokyo - -These are the fingerprints for the Lish gateway in our Tokyo data center (lish-tokyo.linode.com): +lish-tokyo.linode.com RSA af:ec:f0:b8:87:33:d5:12:04:0d:7c:bb:a6:c5:5f:be DSA 1d:7d:bd:5c:a1:41:29:c3:78:de:e7:0f:d3:f2:63:34 ECDSA SHA256 XcBYWsYm4p/bZ/tfWEntUzScDlTxvzTrmd7emeRBMJc ### Tokyo 2 - -These are the fingerprints for the Lish gateway in our Tokyo2 data center (lish-tokyo2.linode.com): +lish-tokyo2.linode.com RSA 2c:60:9a:ce:cf:4b:8d:4e:8f:09:ae:e0:c2:b0:fb:b7 DSA 2d:0f:b0:a5:d0:bd:4a:71:1a:75:dc:de:b1:06:61:a6