Есть различные готовые реализации кластера Kubernetes, например:

• Minikube — готовый кластер, который разворачивается на один компьютер. Хороший способ познакомиться с Kubernetes.
• Kubespray — набор Ansible ролей.
• Готовые кластеры в облаке, например AWS, Google Cloud, Yandex Cloud и так далее.

Использовать одну из готовых реализаций — быстрый и надежный способ развертывания системы оркестрации контейнеров Docker. Однако, мы рассмотрим ручное создание кластера Kubernetes из 3-х нод — один мастер (управление) и две рабочие ноды (запуск контейнеров).

Подготовка системы

Данные действия выполняем на всех узлах будущего кластера. Это необходимо, чтобы удовлетворить программные системные требования для нашего кластера.

Настройка системы

1. Задаем имена узлам. Для этого выполняем команды на соответствующих серверах:

hostnamectl set-hostname k8s-master1.dmosk.local

hostnamectl set-hostname k8s-worker1.dmosk.local

hostnamectl set-hostname k8s-worker2.dmosk.local

* в данном примере мы зададим имя k8s-master1 для мастера и, соответственно, k8s-worker1 и k8s-worker2 — для первого и второго рабочих нод. Каждая команда выполняется на своем сервере.

Необходимо, чтобы наши серверы были доступны по заданным именам. Для этого необходимо на сервере DNS добавить соответствующие А-записи. Или на каждом сервере открываем hosts:

vi /etc/hosts

И добавляем записи на подобие: 

192.168.0.15     k8s-master1.dmosk.local k8s-master1

192.168.0.20     k8s-worker1.dmosk.local k8s-worker1

192.168.0.25     k8s-worker2.dmosk.local k8s-worker2

* где, 192.168.0.15, 192.168.0.20, 192.168.0.25 — IP-адреса наших серверов, k8s-master1, k8s-worker1, k8s-worker2 — имена серверов, dmosk.local — наш внутренний домен.

2. Устанавливаем необходимые компоненты — дополнительные пакеты и утилиты. Для начала, обновим список пакетов и саму систему:

apt-get update && apt-get upgrade

Выполняем установку пакетов:

apt-get install curl apt-transport-https git iptables-persistent

* где:

• git — утилита для работы с GIT. Понадобиться для загрузки файлов из репозитория git.
• curl — утилита для отправки GET, POST и других запросов на http-сервер. Понадобиться для загрузки ключа репозитория Kubernetes.
• apt-transport-https — позволяет получить доступ к APT-репозиториям по протоколу https.
• iptables-persistent — утилита для сохранения правил, созданных в iptables (не обязательна, но повышает удобство).

В процессе установки iptables-persistent может запросить подтверждение сохранить правила брандмауэра — отказываемся.

3. Отключаем файл подкачки. С ним Kubernetes не запустится.

Выполняем команду для разового отключения:

swapoff -a

Чтобы swap не появился после перезагрузки сервера, открываем на редактирование файл:

vi /etc/fstab

И комментируем строку: 

#/swap.img      none    swap    sw      0       0

4. Загружаем дополнительные модули ядра.

vi /etc/modules-load.d/k8s.conf

br_netfilter

overlay

* модуль br_netfilter расширяет возможности netfilter (подробнее); overlay необходим для Docker.

Загрузим модули в ядро:

modprobe br_netfilter

modprobe overlay

Проверяем, что данные модули работают:

lsmod | egrep "br_netfilter|overlay"

Мы должны увидеть что-то на подобие:

overlay               114688  10

br_netfilter           28672  0

bridge                176128  1 br_netfilter

5. Изменим параметры ядра.

Создаем конфигурационный файл:

vi /etc/sysctl.d/k8s.conf 

net.bridge.bridge-nf-call-ip6tables = 1

net.bridge.bridge-nf-call-iptables = 1

* net.bridge.bridge-nf-call-iptables контролирует возможность обработки трафика через bridge в netfilter. В нашем примере мы разрешаем данную обработку для IPv4 и IPv6.

Применяем параметры командой:

sysctl --system

Брандмауэр

Для мастер-ноды и рабочей создаем разные наборы правил.

По умолчанию, в Ubuntu брандмауэр настроен на разрешение любого трафика. Если мы настраиваем наш кластер в тестовой среде, настройка брандмауэра не обязательна.

1. На мастер-ноде (Control-plane)

Выполняем команду:

iptables -I INPUT 1 -p tcp --match multiport --dports 6443,2379:2380,10250:10252 -j ACCEPT

* в данном примере мы открываем следующие порты:

• 6443 — подключение для управления (Kubernetes API).
• 2379:2380 — порты для взаимодействия мастера с воркерами (etcd server client API).
• 10250:10252 — работа с kubelet (соответственно API, scheduler, controller-manager).

Для сохранения правил выполняем команду:

netfilter-persistent save

2. На рабочей ноде (Worker):

На нодах для контейнеров открываем такие порты:

iptables -I INPUT 1 -p tcp --match multiport --dports 10250,30000:32767 -j ACCEPT

* где:

• 10250 — подключение к kubelet API.
• 30000:32767 — рабочие порты по умолчанию для подключения к подам (NodePort Services).

Сохраняем правила командой:

netfilter-persistent save

Установка и настройка Docker

На все узлы кластера выполняем установку Docker следующей командой:

apt-get install docker docker.io

После установки разрешаем автозапуск сервиса docker:

systemctl enable docker

Создаем файл:

vi /etc/docker/daemon.json

{

  "exec-opts": ["native.cgroupdriver=systemd"],

  "log-driver": "json-file",

  "log-opts": {

    "max-size": "100m"

  },

  "storage-driver": "overlay2",

  "storage-opts": [

    "overlay2.override_kernel_check=true"

  ]

}

* для нас является важной настройкой cgroupdriver — она должна быть выставлена в значение systemd. В противном случае, при создании кластера Kubernetes выдаст предупреждение. Хоть на возможность работы последнего это не влияет, но мы постараемся выполнить развертывание без ошибок и предупреждений со стороны системы.

И перезапускаем docker:

systemctl restart docker

Установка Kubernetes

Установку необходимых компонентов выполним из репозитория. Добавим его ключ для цифровой подписи:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

Создадим файл с настройкой репозитория:

vi /etc/apt/sources.list.d/kubernetes.list

deb https://apt.kubernetes.io/ kubernetes-xenial main

Обновим список пакетов:

apt-get update

Устанавливаем пакеты: 

apt-get install kubelet kubeadm kubectl

* где:

• kubelet — сервис, который запускается и работает на каждом узле кластера. Следит за работоспособностью подов.
• kubeadm — утилита для управления кластером Kubernetes.
• kubectl — утилита для отправки команд кластеру Kubernetes.

Нормальная работа кластера сильно зависит от версии установленных пакетов. Поэтому бесконтрольное их обновление может привести к потере работоспособности всей системы. Чтобы этого не произошло, запрещаем обновление установленных компонентов:

apt-mark hold kubelet kubeadm kubectl

Установка завершена — можно запустить команду:

kubectl version --client

… и увидеть установленную версию программы: 

Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", GitCommit:"faecb196815e248d3ecfb03c680a4507229c2a56", GitTreeState:"clean", BuildDate:"2021-01-13T13:28:09Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

Наши серверы готовы к созданию кластера.

Создание кластера

По-отдельности, рассмотрим процесс настройки мастер ноды (control-plane) и присоединения к ней двух рабочих нод (worker).

Настройка control-plane (мастер ноды)

Выполняем команду на мастер ноде:

kubeadm init --pod-network-cidr=10.244.0.0/16

* данная команда выполнит начальную настройку и подготовку основного узла кластера. Ключ —pod-network-cidr задает адрес внутренней подсети для нашего кластера.

Выполнение займет несколько минут, после чего мы увидим что-то на подобие:

...

Then you can join any number of worker nodes by running the following on each as root:



kubeadm join 192.168.0.15:6443 --token f7sihu.wmgzwxkvbr8500al 

    --discovery-token-ca-cert-hash sha256:6746f66b2197ef496192c9e240b31275747734cf74057e04409c33b1ad280321

* данную команду нужно вводить на worker нодах, чтобы присоединить их к нашему кластеру. Можно ее скопировать, но позже мы будем генерировать данную команду по новой.

В окружении пользователя создаем переменную KUBECONFIG, с помощью которой будет указан путь до файла конфигурации kubernetes:

export KUBECONFIG=/etc/kubernetes/admin.conf

Чтобы каждый раз при входе в систему не приходилось повторять данную команду, открываем файл: 

vi /etc/environment

И добавляем в него строку: 

export KUBECONFIG=/etc/kubernetes/admin.conf

Посмотреть список узлов кластера можно командой:

kubectl get nodes

На данном этапе мы должны увидеть только мастер ноду:

NAME                      STATUS     ROLES                  AGE   VERSION

k8s-master.dmosk.local    NotReady   <none>                 10m   v1.20.2

Чтобы завершить настройку, необходимо установить CNI (Container Networking Interface) — в моем примере это flannel:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

* краткий обзор и сравнение производительности CNI можно почитать в статье на хабре.

Узел управления кластером готов к работе.

Настройка worker (рабочей ноды)

Мы можем использовать команду для присоединения рабочего узла, которую мы получили после инициализации мастер ноды или вводим (на первом узле):

kubeadm token create --print-join-command

Данная команда покажет нам запрос на присоединения новой ноды к кластеру, например:

kubeadm join 192.168.0.15:6443 --token f7sihu.wmgzwxkvbr8500al 

    --discovery-token-ca-cert-hash sha256:6746f66b2197ef496192c9e240b31275747734cf74057e04409c33b1ad280321

Копируем его и используем на двух наших узлах. После завершения работы команды, мы должны увидеть:

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

На мастер ноде вводим:

kubectl get nodes

Мы должны увидеть: 

NAME                      STATUS   ROLES                  AGE   VERSION

k8s-master1.dmosk.local   Ready    control-plane,master   18m   v1.20.2

k8s-worker1.dmosk.local   Ready    <none>                 79s   v1.20.2

k8s-worker2.dmosk.local   Ready    <none>                 77s   v1.20.2

Наш кластер готов к работе. Теперь можно создавать поды, развертывания и службы. Рассмотрим эти процессы подробнее.

Pods

Поды — неделимая сущность объекта в Kubernetes. Каждый Pod может включать в себя несколько контейнеров (минимум, 1). Рассмотрим несколько примеров, как работать с подами. Все команды выполняем на мастере.

Создание

Поды создаются командой kubectl, например:

kubectl run nginx --image=nginx:latest --port=80

* в данном примере мы создаем под с названием nginx, который в качестве образа Docker будет использовать nginx (последнюю версию); также наш под будет слушать запросы на порту 80.

Чтобы получить сетевой доступ к созданному поду, создаем port-forward следующей командой:

kubectl port-forward nginx --address 0.0.0.0 8888:80

* в данном примере запросы к кластеру kubernetes на порт 8888 будут вести на порт 80 (который мы использовали для нашего пода).

Команда kubectl port-forward является интерактивной. Ее мы используем только для тестирования. Чтобы пробросить нужные порты в Kubernetes используются Services — об этом будет сказано ниже.

Можно открыть браузер и ввести адрес http://<IP-адрес мастера>:8888 — должна открыться страница приветствия для NGINX.

Просмотр

Получить список всех подов в кластере можно командой:

kubectl get pods

Например, в нашем примере мы должны увидеть что-то на подобие:

NAME    READY   STATUS    RESTARTS   AGE

nginx   1/1     Running   0          3m26s

Посмотреть подробную информацию о конкретном поде можно командой:

kubectl describe pods nginx

Запуск команд внутри контейнера

Мы можем запустить одну команду в контейнере, например, такой командой:

kubectl exec nginx -- date

* в данном примере будет запущена команда date внутри контейнера nginx.

Также мы можем подключиться к командной строке контейнера командой:

kubectl exec --tty --stdin nginx -- /bin/bash

Удаление

Для удаления пода вводим:

kubectl delete pods nginx

Использование манифестов

В продуктивной среде управление подами выполняется с помощью специальных файлов с описанием того, как должен создаваться и настраиваться под — манифестов. Рассмотрим пример создания и применения такого манифеста.

Создадим файл формата yml:

vi manifest_pod.yaml

apiVersion: v1

kind: Pod

metadata: 

  name: web-srv

  labels:

    app: web_server

    owner: dmosk

    description: web_server_for_site

spec:

  containers: 

    - name: nginx

      image: nginx:latest

      ports:

        - containerPort: 80

        - containerPort: 443



    - name: php-fpm

      image: php-fpm:latest

      ports:

        - containerPort: 9000



    - name: mariadb

      image: mariadb:latest

      ports:

        - containerPort: 3306

* в данном примере будет создан под с названием web-srv; в данном поде будет развернуто 3 контейнера — nginx, php-fpm и mariadb на основе одноименных образов.

Для объектов Kubernetes очень важное значение имеют метки или labels. Необходимо всегда их описывать. Далее, данные метки могут использоваться для настройки сервисов и развертываний.

Чтобы применить манифест выполняем команду:

kubectl apply -f manifest_pod.yaml

Мы должны увидеть ответ:

pod/web-srv created

Смотрим поды командой:

kubectl get pods

Мы должны увидеть:

NAME      READY   STATUS    RESTARTS   AGE

web-srv   3/3     Ready     0          3m11s

* для Ready мы можем увидеть 0/3 или 1/3 — это значит, что контейнеры внутри пода еще создаются и нужно подождать.

Deployments

Развертывания позволяют управлять экземплярами подов. С их помощью контролируется их восстановление, а также балансировка нагрузки. Рассмотрим пример использования Deployments в Kubernetes.

Создание

Deployment создаем командой со следующим синтаксисом:

kubectl create deploy <название для развертывания> --image <образ, который должен использоваться>

Например:

kubectl create deploy web-set --image nginx:latest

* данной командой мы создадим deployment с именем web-set; в качестве образа будем использовать nginx:latest.

Просмотр

Посмотреть список развертываний можно командой:

kubectl get deploy

Подробное описание для конкретного развертывания мы можем посмотреть так:

kubectl describe deploy web-set

* в данном примере мы посмотрим описание deployment с названием web-set.

Scaling

Как было написано выше, deployment может балансировать нагрузкой. Это контролируется параметром scaling:

kubectl scale deploy web-set --replicas 3

* в данном примере мы указываем для нашего созданного ранее deployment использовать 3 реплики — то есть Kubernetes создаст 3 экземпляра контейнеров.

Также мы можем настроить автоматическую балансировку:

kubectl autoscale deploy web-set --min=5 --max=10 --cpu-percent=75

В данном примере Kubernetes будет создавать от 5 до 10 экземпляров контейнеров — добавление нового экземпляра будет происходить при превышении нагрузки на процессор до 75% и более.

Посмотреть созданные параметры балансировки можно командой:

kubectl get hpa

Редактирование

Для нашего развертывания мы можем изменить используемый образ, например:

kubectl set image deploy/web-set nginx=httpd:latest --record

* данной командой для deployment web-set мы заменим образ nginx на httpd; ключ record позволит нам записать действие в историю изменений.

Если мы использовали ключ record, то историю изменений можно посмотреть командой:

kubectl rollout history deploy/web-set

Перезапустить deployment можно командой:

kubectl rollout restart deploy web-set

Манифест

Как в случае с подами, для создания развертываний мы можем использовать манифесты. Попробуем рассмотреть конкретный пример.

Создаем новый файл:

vi manifest_deploy.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: web-deploy

  labels:

    app: web_server

    owner: dmosk

    description: web_server_for_site

spec:

  replicas: 5

  selector:

    matchLabels:

      project: myweb

  template:

    metadata:

      labels:

        project: myweb

        owner: dmosk

        description: web_server_pod

    spec:

      containers:

        - name: myweb-httpd

          image: httpd:latest

          ports:

            - containerPort: 80

            - containerPort: 443

            

---

apiVersion: autoscaling/v2beta2

kind: HorizontalPodAutoscaler

metadata:

  name: web-deploy-autoscaling

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: myweb-autoscaling

  minReplicas: 5

  maxReplicas: 10

  metrics:

  - type: Resource

    resource:

      name: cpu

      target:

        type: Utilization

        averageUtilization: 75

  - type: Resource

    resource:

      name: memory

      target:

        type: Utilization

        averageUtilization: 80

* в данном манифесте мы создадим deployment и autoscaling. Итого, мы получим 5 экземпляров подов для развертывания web-deploy, которые могут быть расширены до 10 экземпляров. Добавление нового будет происходить при превышении нагрузки на процессор более чем на 75% или потреблением оперативной памяти более чем на 80%.

Чтобы создать объекты с помощью нашего манифеста вводим:

kubectl apply -f manifest_deploy.yaml

Мы должны увидеть:

deployment.apps/web-deploy created

horizontalpodautoscaler.autoscaling/web-deploy-autoscaling created

Объекты web-deploy и web-deploy-autoscaling созданы.

Удаление

Для удаления конкретного развертывания используем команду:

kubectl delete deploy web-set

Для удаления всех развертываний вместо названия deployment указываем ключ —all:

kubectl delete deploy --all

Удалить критерии autoscaling для конкретного развертывания можно командой:

kubectl delete hpa web-set

Удалить все критерии autoscaling можно командой:

kubectl delete hpa --all

Удалить объекты, созданные с помощью манифеста можно командой:

kubectl delete -f manifest_deploy.yaml

Services

Службы позволяют обеспечить сетевую доступность для развертываний. Существует несколько типов сервисов:

• ClusterIP — сопоставление адреса с deployments для подключений внутри кластера Kubernetes.
• NodePort — для внешней публикации развертывания.
• LoadBalancer — сопоставление через внешний балансировщик.
• ExternalName — сопоставляет службу по имени (возвращает значение записи CNAME).

Мы рассмотрим первые два варианта.

Привязка к Deployments

Попробуем создать сопоставления для ранее созданного развертывания:

kubectl expose deploy web-deploy --type=ClusterIP --port=80

* где web-deploy — deployment, который мы развернули с помощью манифеста. Публикация ресурса происходит на внутреннем порту 80. Обращаться к контейнерам можно внутри кластера Kubernetes.

Для создания сопоставления, с помощью которого можно будет подключиться к контейнерам из внешней сети выполняется командой:

kubectl expose deploy web-deploy --type=NodePort --port=80

* данная команда отличается от команды выше только типом NodePort — для данному deployment будет сопоставлен порт для внешнего подключения, который будет вести на внутренний (в нашем примере, 80).

Просмотр

Чтобы посмотреть созданные нами службы, вводим:

kubectl get services

Мы можем увидеть что-то на подобие:

NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE

web-deploy   NodePort    10.111.229.132   <none>        80:30929/TCP   21s

* в данном примере указано, что у нас есть служба типа NodePort, а к сервису можно подключиться по порту 30929.

Можно попробовать открыть браузер и ввести http://<IP-адрес мастера>:30929 — мы должны увидеть нужную нам страницу (в наших примерах, либо NGINX, либо Apache).

Посмотреть список сервисов с указанием селектором можно командой:

kubectl get services -o wide

Удаление

Удаляем созданную службу командой:

kubectl delete services web-deploy

* в данном примере будет удалена служба для развертывания web-deploy.

Удалить все службы можно командой:

kubectl delete services --all

Манифест

Как в случае с подами и развертываниями, мы можем использовать манифест-файлы. Рассмотрим небольшой пример.

vi manifest_service.yaml

apiVersion: v1

kind: Service

metadata:

  name: web-service

  labels:

    app: web_server

    owner: dmosk

    description: web_server_for_site

spec:

  selector:

    project: myweb

  type: NodePort

  ports:

    - name: app-http

      protocol: TCP

      port: 80

      targetPort: 80



    - name: app-smtp

      protocol: TCP

      port: 25

      targetPort: 25

* в данном примере мы создадим службу, которая будем связываться с развертыванием по лейболу project: myweb.

Ingress Controller

В данной инструкции не будет рассказано о работе с Ingress Controller. Оставляем данный пункт для самостоятельного изучения.

Данное приложение позволяет создать балансировщик, распределяющий сетевые запросы между нашими сервисами. Порядок обработки сетевого трафика определяем с помощью Ingress Rules.

Существует не маленькое количество реализаций Ingress Controller — их сравнение можно найти в документе по ссылке в Google Docs.

Для установки Ingress Controller Contour (среди множества контроллеров, он легко устанавливается и на момент обновления данной инструкции полностью поддерживает последнюю версию кластера Kubernetes) вводим:

kubectl apply -f https://projectcontour.io/quickstart/contour.yaml

Установка веб-интерфейса

Веб-интерфейс позволяет получить информацию о работе кластера в удобном для просмотра виде.

В большинстве инструкций рассказано, как получить доступ к веб-интерфейсу с того же компьютера, на котором находится кластер (по адресу 127.0.0.1 или localhost). Но мы рассмотрим настройку для удаленного подключения, так как это более актуально для серверной инфраструктуры.

Переходим на страницу веб-интерфейса в GitHub и копируем ссылку на последнюю версию файла yaml:

* на момент обновления инструкции, последняя версия интерфейса была 2.1.0.

Скачиваем yaml-файл командой:

wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.1.0/aio/deploy/recommended.yaml

* где https://raw.githubusercontent.com/kubernetes/dashboard/v2.1.0/aio/deploy/recommended.yaml — ссылка, которую мы скопировали на портале GitHub.

Открываем на редактирование скачанный файл:

vi recommended.yaml

Комментируем строки для kind: Namespace и kind: Secret (в файле несколько блоков с kind: Secret — нам нужен тот, что с name: kubernetes-dashboard-certs):

...

#apiVersion: v1

#kind: Namespace

#metadata:

#  name: kubernetes-dashboard

...

#apiVersion: v1

#kind: Secret

#metadata:

#  labels:

#    k8s-app: kubernetes-dashboard

#  name: kubernetes-dashboard-certs

#  namespace: kubernetes-dashboard

#type: Opaque

* нам необходимо закомментировать эти блоки, так как данные настройки в Kubernetes мы должны будем сделать вручную.

Теперь в том же файле находим kind: Service (который с name: kubernetes-dashboard) и добавляем строки type: NodePort и nodePort: 30001 (выделены красным):

kind: Service

apiVersion: v1

metadata:

  labels:

    k8s-app: kubernetes-dashboard

  name: kubernetes-dashboard

  namespace: kubernetes-dashboard

spec:

  type: NodePort

  ports:

    - port: 443

      targetPort: 8443

      nodePort: 30001

  selector:

    k8s-app: kubernetes-dashboard

* таким образом, мы публикуем наш сервис на внешнем адресе и порту 30001.

Для подключения к веб-интерфейсу не через локальный адрес, начиная с версии 1.17, обязательно необходимо использовать зашифрованное подключение (https). Для этого нужен сертификат. В данной инструкции мы сгенерируем самоподписанный сертификат — данный подход удобен для тестовой среды, но в продуктивной среде необходимо купить сертификат или получить его бесплатно в Let’s Encrypt.

И так, создаем каталог, куда разместим наши сертификаты:

mkdir -p /etc/ssl/kubernetes

Сгенерируем сертификаты командой:

openssl req -new -x509 -days 1461 -nodes -out /etc/ssl/kubernetes/cert.pem -keyout /etc/ssl/kubernetes/cert.key -subj "/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=kubernetes.dmosk.local/CN=kubernetes"

* можно не менять параметры команды, а так их и оставить. Браузер все-равно будет выдавать предупреждение о неправильном сертификате, так как он самоподписанный.

Создаем namespace:

kubectl create namespace kubernetes-dashboard

* это та первая настройка, которую мы комментировали в скачанном файле recommended.yaml.

Теперь создаем настройку для secret с использованием наших сертификатов:

kubectl create secret generic kubernetes-dashboard-certs --from-file=/etc/ssl/kubernetes/cert.key --from-file=/etc/ssl/kubernetes/cert.pem -n kubernetes-dashboard

* собственно, мы не использовали настройку в скачанном файле, так как создаем ее с включением в параметры пути до созданных нами сертификатов.

Теперь создаем остальные настройки с помощью скачанного файла:

kubectl create -f recommended.yaml

Мы увидим что-то на подобие:

serviceaccount/kubernetes-dashboard created

service/kubernetes-dashboard created

secret/kubernetes-dashboard-csrf created

secret/kubernetes-dashboard-key-holder created

configmap/kubernetes-dashboard-settings created

role.rbac.authorization.k8s.io/kubernetes-dashboard created

clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created

rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created

clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created

deployment.apps/kubernetes-dashboard created

service/dashboard-metrics-scraper created

deployment.apps/dashboard-metrics-scraper created

Создадим настройку для админского подключения:

vi dashboard-admin.yaml

apiVersion: v1

kind: ServiceAccount

metadata:

  labels:

    k8s-app: kubernetes-dashboard

  name: dashboard-admin

  namespace: kubernetes-dashboard



---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

  name: dashboard-admin-bind-cluster-role

  labels:

    k8s-app: kubernetes-dashboard

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

  name: cluster-admin

subjects:

- kind: ServiceAccount

  name: dashboard-admin

  namespace: kubernetes-dashboard

Создаем настройку с применением созданного файла:

kubectl create -f dashboard-admin.yaml

Теперь открываем браузер и переходим по ссылке https://<IP-адрес мастера>:30001 — браузер покажет ошибку сертификата (если мы настраиваем по инструкции и сгенерировали самоподписанный сертификат). Игнорируем ошибку и продолжаем загрузку.

Kubernetes Dashboard потребует пройти проверку подлинности. Для этого можно использовать токен или конфигурационный файл:

На сервере вводим команду для создания сервисной учетной записи:

kubectl create serviceaccount dashboard-admin -n kube-system

Создадим привязку нашего сервисного аккаунта с Kubernetes Dashboard:

kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin

Теперь камандой:

kubectl describe secrets -n kube-system $(kubectl -n kube-system get secret | awk '/dashboard-admin/{print $1}')

… получаем токен для подключения (выделен красным): 

Data

====

ca.crt:     1066 bytes

namespace:  11 bytes

token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IkpCT0J5TWF2VWxWQUotdHZYclFUaWwza2NfTW1IZVNuSlZSN3hWUzFrNTAifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkYXNoYm9hcmQtYWRtaW4tdG9rZW4tbnRqNmYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGFzaGJvYXJkLWFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiMzIwNjVhYmQtNzAwYy00Yzk5LThmZjktZjc0YjM5MTU0Y2VhIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmRhc2hib2FyZC1hZG1pbiJ9.wvDGeNiTCRBakDplO6PbdqvPH_W2EsBgJjZnTDflneP3cdXQv6VgBkI8NalplXDRF-lF36KbbC2hpRjbkblrLW7BemIVWYOznmc8kmrgCSxO2FVi93NK3biE9TkDlj1BbdiyfOO86L56vteXGP20X0Xs1h3cjAshs-70bsnJl6z3MY5GbRVejOyVzq_PWMVYsqvQhssExsJM2tKJWG0DnXCW687XHistbYUolhxSRoRpMZk-JrguuwgLH5FYIIU-ZdTZA6mz-_hqrx8PoDvqEfWrsniM6Q0k8U3TMaDLlduzA7rwLRJBQt3C0aD6XfR9wHUqUWd5y953u67wpFPrSA

Используя полученный токен, вводим его в панели авторизации:

Мы должны увидеть стартовое окно системы управления:

Удаление нод

При необходимости удалить ноду из нашего кластера, вводим 2 команды:

kubectl drain k8s-worker2.dmosk.local --ignore-daemonsets

kubectl delete node k8s-worker2.dmosk.local

* в данном примере мы удаляем ноду k8s-worker2.dmosk.local.

Источник: https://www.dmosk.ru/instruktions.php?object=kubernetes-ubuntu

Рассмотренные примеры подойдут для Linux Ubuntu версий 16, 18 и 20.

Подготовка системы

Синхронизируем время.

Устанавливаем утилиту chrony:

apt-get install chrony

Выставляем нужный часовой пояс:

timedatectl set-timezone Europe/Moscow

* в данном примере московское время.

Разрешаем запуск демона chrony:

systemctl enable chrony

Настройка сервера баз данных

В качестве СУБД используем MariaDB.

Устанавливаем:

apt-get install mariadb-server

Разрешаем автозапуск и стартуем сервис:

systemctl enable mariadb

systemctl start mariadb

Задаем пароль для суперпользователя mysql:

mysqladmin -u root password

Подключаемся к MariaDB, создаем базу данных и пользователя:

mysql -uroot -p

> CREATE DATABASE nextcloud DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

> GRANT ALL PRIVILEGES ON nextcloud.* TO nextcloud@localhost IDENTIFIED BY 'nextcloud';

> q

Установка и настройка веб-сервера

PHP

Устанавливаем PHP, PHP-FPM и необходимые для работы nextcloud модули:

apt-get install php php-fpm php-common php-zip php-xml php-intl php-gd php-mysql php-mbstring php-curl php-imagick

Настраиваем php-fpm:

vi /etc/php/7.4/fpm/pool.d/www.conf

* путь к данной папке зависит от установленной версии php. В данном примере это 7.4.

Снимаем комментарии со следующей строки:

env[PATH] = /usr/local/bin:/usr/bin:/bin

Настраиваем php.ini:

vi /etc/php/7.4/fpm/php.ini

opcache.enable=1

opcache.enable_cli=1

opcache.interned_strings_buffer=8

opcache.max_accelerated_files=10000

opcache.memory_consumption=128

opcache.save_comments=1

opcache.revalidate_freq=1

Разрешаем автозапуск php-fpm и перезапускаем его:

systemctl enable php7.4-fpm

systemctl restart php7.4-fpm

* php7.4-fpm зависит от версии установленного php.

NGINX

Nextcloud можно развернуть на NGINX или Apache. В данной инструкции будем использовать первый.

Устанавливаем веб-сервер:

apt-get install nginx

Создаем виртуальный домен и настраиваем его для работы с облачным сервисом:

vi /etc/nginx/conf.d/nextcloud.conf

server {

        listen 80;

        server_name nextcloud.dmosk.ru;

        return 301 https://$server_name$request_uri;

}



server {

        listen 443 ssl;

        server_name nextcloud.dmosk.ru;



        ssl_certificate /etc/nginx/ssl/cert.pem;

        ssl_certificate_key /etc/nginx/ssl/cert.key;



        root /var/www/nextcloud;



        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

        client_max_body_size 10G;

        fastcgi_buffers 64 4K;



        rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;

        rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;

        rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;



        index index.php;

        error_page 403 = /core/templates/403.php;

        error_page 404 = /core/templates/404.php;



        location = /robots.txt {

            allow all;

            log_not_found off;

            access_log off;

        }



        location ~ ^/(data|config|.ht|db_structure.xml|README) {

                deny all;

        }



        location / {

                rewrite ^/.well-known/host-meta /public.php?service=host-meta last;

                rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

                rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;

                rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;

                rewrite ^(/core/doc/[^/]+/)$ $1/index.html;

                try_files $uri $uri/ index.php;

        }



        location ~ ^(.+?.php)(/.*)?$ {

                try_files $1 = 404;

                include fastcgi_params;

                fastcgi_param SCRIPT_FILENAME $document_root$1;

                fastcgi_param PATH_INFO $2;

                fastcgi_param HTTPS on;

                fastcgi_pass unix:/run/php/php7.4-fpm.sock;

        }



        location ~* ^.+.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {

                expires modified +30d;

                access_log off;

        }

}

* где nextcloud.dmosk.ru — домен, на котором будет работать сервис; /etc/nginx/ssl — каталог, в котором будут храниться сертификаты; /var/www/nextcloud — каталог с порталом.

Создаем каталог для хранения сертификатов и переходим в него:

mkdir /etc/nginx/ssl

cd /etc/nginx/ssl

Генерируем сертификат:

openssl req -new -x509 -days 1461 -nodes -out cert.pem -keyout cert.key -subj "/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=nextcloud.dmosk.ru/CN=nextcloud"

* данная команда создаст сертификат на 4 года для URL nextcloud.dmosk.ru или nextcloud.

После установки php мог установиться и запуститься apache. Отключаем его:

systemctl stop apache2

systemctl disable apache2

Проверяем конфигурацию nginx, завершаем его автозапуск и перезапускаем сервис:

nginx -t

systemctl enable nginx

systemctl restart nginx

Установка Nextcloud

Устанавливаем пакет unzip:

apt-get install unzip

Заходим на страницу nextcloud и копируем ссылку на скачивание последней версии программы:

Переходим во временную папку и скачиваем исходник для установки, воспользовавшись скопированной ссылкой:

cd /tmp

wget https://download.nextcloud.com/server/releases/nextcloud-19.0.3.zip

Распаковываем скачанный архив:

unzip nextcloud-*.zip

И переносим содержимое архива в каталог /var/www:

mv nextcloud /var/www

Задаем права доступа:

chown -R www-data:www-data /var/www/nextcloud

Открываем браузер и переходим по адресу https://nextcloud.dmosk.ru, где nextcloud.dmosk.ru — адрес облачного сервиса.

Задаем логин и пароль для администратора. В качестве базы данных выбираем MySQL/MariaDB (если предлагается выбор) и вводим в качестве логина, пароля и базы nextcloud.

Завершаем установку.

Оптимизируем работу базы данных:

sudo -u www-data php /var/www/nextcloud/occ db:convert-filecache-bigint

Тюнинг после установки

Для корректной работы системы выполним дополнительную настройку. После входа в nextcloud под администратором, переходим в настройки для пользователя:

В разделе «Параметры сервера» переходим в Основные сведения:

В разделе «Проверка безопасности и параметров» мы можем увидеть список проблем:

Рассмотрим процесс решения некоторых из них.

1. Разрешённое максимальное значение использования памяти PHP ниже рекомендуемого значения в 512 МБ

Открываем на редактирование файл:

vi /etc/php/7.4/fpm/php.ini

Меняем настройку для memory_limit:

memory_limit = 512M

Перезапускаем php-fpm:

systemctl restart php7.4-fpm

2. В системе не установлены рекомендуемые модули PHP

Данная ошибка устраняется в зависимости от списка модулей, которых не хватает системе. Чаще всего, подходит команда:

dnf install php-<название модуля>

Например:

apt-get install php-gmp php-bcmath

После перезапускаем php-fpm:

systemctl restart php7.4-fpm

3. Не настроена система кеширования

Для решения проблемы мы должны установить и настроить одно из средств кэширования:

• APCu
• Redis
• Memcached

Мы рассмотрим последний вариант. Для этого выполняем установку модуля для php и сам сервис memcached:

apt-get install memcached php-memcached

После разрешаем его автозапуск:

systemctl enable memcached

Перезапускаем php-fpm:

systemctl restart php7.4-fpm

После этого открываем конфигурационный файл для nextcloud:

vi /var/www/nextcloud/config/config.php

И добавим:

 ...

  'memcache.local' => '\OC\Memcache\Memcached',

  'memcache.distributed' => '\OC\Memcache\Memcached',

  'memcached_servers' =>

  array (

    0 =>

    array (

      0 => 'localhost',

      1 => 11211,

    ),

  ),

  ...

Готово.

Работа с пользователями из UNIX-Shell

В состав nextcloud входит php-скрипт occ, с помощью которого можно управлять сервисом из командной строки Linux.

Добавление пользователя

Создать нового пользователя можно командой:

sudo -u www-data php /var/www/nextcloud/occ user:add admin

* где admin — имя учетной записи.

Сброс пароля

При необходимости сбросить пароль пользователя, можно воспользоваться командой:

sudo -u www-data php /var/www/nextcloud/occ user:resetpassword admin

* где admin — учетная запись пользователя, чей пароль хотим сбросить.

Подключение папки nextcloud по webdav

Мы можем подключить пользовательские данные nextcloud в качестве сетевого диска или раздела. Рассмотрим процесс для Windows и Linux.

Windows

Для начала необходимо включить службу «Веб-клиент». Для этого открываем от администратора командную строку и вводим команды:

sc config webclient start= auto

net start webclient

* первая команда включит автозапуск службы; вторая — запустит ее.

После открываем командную строку от пользователя и создаем сетевой диск командой:

net use <Буква диска>: https://<путь до nextcloud>/remote.php/webdav /user:user password

Например, для нашей настройки:

net use N: https://nextcloud.dmosk.ru/remote.php/webdav /user:admin password

* где N — буква сетевого диска; nextcloud.dmosk.ru — адрес нашего сервера; admin — учетная запись, которая была создана при установке системы; password — пароль от пользователя admin.

Ограничение на копирование файла с webdav

В Windows при попытке скопировать большой файл с папки webdav, мы можем получить ошибку «Ошибка 0x800700DF: Размер файла превышает установленное ограничение, сохранение файла невозможно.»:

Для решения проблемы необходимо на клиенте разрешить больший объем для загрузки файлов. Это делается в реестре — ветка HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWebClientParameters, параметр FileSizeLimitInBytes. Для примера, если задать значение 4294967295 (максимально возможное), то мы получим ограничение в 4 Гб.

Также можно воспользоваться командой:

reg add "HKLMSYSTEMCurrentControlSetServicesWebClientParameters" /v FileSizeLimitInBytes /t REG_DWORD /d 4294967295 /f

* команду нужно запускать в консоли, запущенной от администратора. В данном примере мы задаем также ограничение в 4 Гб.

Linux

Установим клиент davfs2. Действия будут немного различаться в зависимости от дистрибутива Linux.

а) Ubuntu / Debian:

apt-get install davfs2

б) CentOS / Red Hat:

yum install davfs2

Теперь мы можем примонтировать 

mount -t davfs -o noexec https://nextcloud.dmosk.ru/remote.php/webdav /mnt

* в данном примере мы запустим команду на монтирование раздела по webdav в каталог /mnt. Обращение выполняется на наш сервер nextcloud.dmosk.ru.

После ввода команды, система попросит нас ввести логин и пароль от учетной записи Nextcloud:

  Username: user

  ...

  Password:  

После каталог будет примонтирован.

Для постоянного монтирования серез fstab, открываем файл:

vi /etc/fstab

Добавляем строчку:

https://nextcloud.dmosk.ru/remote.php/webdav/    /mnt    davfs    user,rw,_netdev 0 0

После открываем файл:

vi /etc/davfs2/secrets

И добавляем строку:

/mnt user password

* где /mnt — предполагаемый каталог, куда мы будем монтировать данные; user и password — логин и пароль от учетной записи в Nextcloud.

Монтируем каталог командой:

mount -a

Источник: https://www.dmosk.ru/miniinstruktions.php?mini=nextcloud-ubuntu

В данной инструкции выполнена настройка полноценного почтового сервера на Linux Ubuntu Server (протестирована на версии 20.04). Список всех особенностей и возможностей:

• Поддержка шифрования;
• Хранение почты на сервере;
• Защита от СПАМа и вирусов;
• Почтовая система на базе Postfix;
• Поддержка виртуальных доменов;
• Хранение части настроек в MariaDB;
• Доступ к почте с помощью веб-интерфейса (Roundcube);
• Подключение к почтовым ящикам по POP3 и IMAP (Dovecot);
• Возможность управления почтовыми ящиками с помощью PostfixAdmin.

1. Подготовка системы

И так, данная инструкция написана под систему Linux Ubuntu Server. Предварительно, выполним следующие действия.

Общие настройки

Обновляем систему:

apt-get update && apt-get upgrade

Задаем правильное имя серверу — это важный шаг, так как большинство антиспам систем выполняют проверки, обращаясь к серверу по имени в ожидании ответа:

hostnamectl set-hostname relay.dmosk.ru

* необходимо указать FQDN-имя, которое будет доступно из глобальной сети. В данном примере указано relay.dmosk.ru.

Устанавливаем пакет для синхронизации времени:

apt-get install chrony

Задаем временную зону (в данном примере московское время):

timedatectl set-timezone Europe/Moscow

* чтобы получить список всех возможных зон, вводим timedatectl list-timezones.

Разрешаем сервис для обновления времени:

systemctl enable chrony

Настройка безопасности

Заранее открываем порты на брандмауэре с помощью iptables:

iptables -I INPUT 1 -p tcp --match multiport --dports 25,110,143,465,587,993,995 -j ACCEPT

iptables -I INPUT 1 -p tcp --match multiport --dports 80,443 -j ACCEPT

* где мы откроем следующие порты:

• 25 — стандартный SMTP через STARTTLS;
• 110 — стандартный POP3 через STARTTLS;
• 143 — стандартный IMAP через STARTTLS;
• 465 — защищенный SMTP через SSL/TLS;
• 587 — защищенный SMTP через STARTTLS;
• 993 — защищенный IMAP через SSL/TLS;
• 995 — защищенный POP3 через SSL/TLS.
• 80 — HTTP для порталов Postfixadmin и Roundcube;
• 443 — защищенный HTTPS для порталов Postfixadmin и Roundcube;

Для сохранения правил установим пакет:

apt-get install iptables-persistent

И выполняем команду:

netfilter-persistent save

2. Настройка веб-сервера: NGINX + PHP + MariaDB

Система управления PostfixAdmin работает как веб-приложение, разработанное на PHP, а информацию хранит в базе данных. В нашем примере будет использоваться веб-сервер на NGINX, а база данных — MariaDB.

Установка NGINX

Устанавливаем nginx командой:

apt-get install nginx

Разрешаем автозапуск сервиса:

systemctl enable nginx

Проверяем работоспособность веб-сервера, обратившись к нему в браузере по адресу http://<IP-адрес сервера>. Если видим заголовок «Welcome to nginx!», NGINX настроен верно.

PHP + PHP-FPM + NGINX

Устанавливаем php и php-fpm:

apt-get install php php-fpm

Настраиваем NGINX:

vi /etc/nginx/sites-enabled/default

В разделах http — server указываем, чтобы первым индексным файлом был index.php, а также добавляем настройку для обработки запросов php (location):

server {

        listen 80 default_server;

        listen [::]:80 default_server;

        ...



        index index.php ...

        ...



        location ~ .php$ {

            set $root_path /var/www/html;

            fastcgi_pass unix:/run/php/php7.4-fpm.sock;

            fastcgi_index index.php;

            fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;

            include fastcgi_params;

            fastcgi_param DOCUMENT_ROOT $root_path;

        }

}

* где /var/www/html — каталог для размещения данных nginx по умолчанию; /run/php/php7.4-fpm.sock — путь до сокет-файла php-fpm (обратите внимание, что точное значение зависит от используемой вервии php).

Разрешаем автозапуск php-fpm:

systemctl enable php7.4-fpm

* где php7.4-fpm зависит от используемой версии php, которую можно посмотреть командой php -v.

Перезапускаем nginx: 

systemctl restart nginx

Для проверки, создаем индексный файл в директории сайта со следующим содержимым:

vi /var/www/html/index.php

<?php phpinfo(); ?>

Открываем сайт в браузере по его IP-адресу. На открывшейся странице мы должны увидеть подробную информацию по php:

MariaDB

Устанавливаем сервер баз данных следующей командой:

apt-get install mariadb-server

Включаем автозапуск сервиса баз данных:

systemctl enable mariadb

Задаем пароль для пользователя sql root:

mysqladmin -u root password

3. Установка и настройка PostfixAdmin

Устанавливаем дополнительные компоненты для PHP:

apt-get install php-mysql php-mbstring php-imap

Для применения установленных пакетов, перезапускаем обработчик скриптов:

systemctl restart php7.4-fpm

Скачиваем PostfixAdmin:

wget https://sourceforge.net/projects/postfixadmin/files/latest/download -O postfixadmin.tar.gz

В директории сайтов nginx создаем каталог для postfixadmin и распаковываем в него архив:

mkdir /var/www/html/postfixadmin

tar -C /var/www/html/postfixadmin -xvf postfixadmin.tar.gz --strip-components 1

Создаем каталог templates_c внутри папки портала (без него не запустится установка):

mkdir /var/www/html/postfixadmin/templates_c

* в противном случае, при попытке зайти в панель управления после ее установки мы получим ошибку ERROR: the templates_c directory doesn’t exist or isn’t writeable for the webserver.

Задаем права на каталог:

chown -R www-data:www-data /var/www/html/postfixadmin

* несмотря на то, что мы используем веб-сервер nginx, php-fpm по умолчанию, запускается от пользователя www-data.

Создаем базу данных postfix и учетную запись в mariadb:

mysql -u root -p

> CREATE DATABASE postfix DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

* где postfix — имя базы.

> GRANT ALL ON postfix.* TO 'postfix'@'localhost' IDENTIFIED BY 'postfix123';

* где postfix — имя учетной записи; postfix123 — пароль; localhost разрешает подключение только с локального сервера.

Выходим из командной оболочки MariaDB:

> q

Создаем конфигурационный файл postfixadmin:

vi /var/www/html/postfixadmin/config.local.php

* в предыдущих версиях использовался файл config.inc.php. В новых версиях его не рекомендуется править, а использовать config.local.php, который переопределяет настройки.

И добавляем следующее:

<?php



$CONF['configured'] = true;

$CONF['default_language'] = 'ru';

$CONF['database_password'] = 'postfix123';

$CONF['emailcheck_resolve_domain']='NO';



?>

* где configured говорит приложению, что администратор закончил его конфигурирование; default_language — используемый язык по умолчанию; database_password — пароль для базы данных, который мы задали на предыдущем шаге; emailcheck_resolve_domain — задает необходимость проверки домена при создании ящиков и псевдонимов.

Запускаем браузер и вводим адрес http://<IP-адрес сервера>/postfixadmin/public/setup.php — откроется страница для установки PostfixAdmin. 

Задаем дважды пароль установки и генерируем хэш, кликнув по Generate setup_password hash:

После копируем хэш, который появится под кнопкой:

Открываем конфигурационный файл:

vi /var/www/html/postfixadmin/config.local.php

И добавляем строчку:

...

$CONF['setup_password'] = '$2y$10$D...R32';

* где ‘$2y$10$D…R32’ — скопированный хэш.

Перезагружаем страницу http://<IP-адрес сервера>/postfixadmin/public/setup.php — теперь у нас появится форма для ввода нашего пароля, созданного на предыдущем этапе. Вводим его и кликаем по Login with setup_password:

Будет выполнена установка PostfixAdmin.

Если в процессе установки система выведет ошибки, необходимо самостоятельно с ними разобраться. Как правило, они могут сводиться к отсутствию необходимых пакетов, которых может не оказаться в системе по умолчанию.

После установки в нижней части страницы должна быть форма добавления суперпользователя — вводим данные:

* где Setup password — пароль, который мы ввели на предыдущей странице; Админ — учетная запись для входа в панель управления PostfixAdmin; Пароль — новый пароль для создаваемой учетной записи.

Установка завершена. Переходим в браузере на страницу http://<IP-адрес сервера>/postfixadmin/public/login.php

Вводим логин и пароль для созданного пользователя. Мы должны войти в postfix.admin.

Однако, конкретно, в моем случае, пользователь не создавался при установке системы и необходимо было создать администратора вручную. Если это потребуется, в консоли сервера подключаемся к СУБД:

mysql -uroot -p

Переходим к использованию базы postfix:

> use postfix

Добавляем администратора запросом:

> INSERT INTO admin (`username`, `password`, `superadmin`, `active`) VALUES ('root@dmosk.ru', '$1$1b7ff416$/KKYqdyAd3viA3.PNu5hh/', '1', '1');

Выходим из sql-оболочки:

> quit

Теперь переходим на страницу http://<IP-адрес сервера>/postfixadmin/public/login.php вводим логин root@dmosk.ru и пароль qwe12345 — мы должны оказаться в системе управления почтой. Первым делом, переходим в Список админов — Новый админ:

Создаем своего пользователя. После чего, можно удалить того, что создали через командную строку.

4. Установка и настройка Postfix

Установка Postfix в Ubuntu выполняется командой:

apt-get install postfix postfix-mysql

* помимо самого postfix, мы также установим postfix-mysql для возможности работы с СУБД.

В процессе установки должно появиться окно «Postfix Configuration» — оставляем Internet Site:

В следующем окне оставляем имя сервера и нажимаем Enter.

После установки пакетов создаем учетную запись, от которой мы будем работать с каталогом виртуальных почтовых ящиков:

groupadd -g 1024 vmail

useradd -d /home/mail -g 1024 -u 1024 vmail -m

* сначала мы создаем группу vmail и guid 1024, после — пользователя vmail с uid 1024 и домашней директорией /home/mail — в ней у нас будет храниться почта. Обратите внимание, что в некоторых системах идентификатор группы и пользователя 1024 может быть занят. В таком случае необходимо создать другой, а в данной инструкции ниже заменить все 1024 на альтернативный.

Если директория для почты ранее уже была создана, то необходимо задать в качестве владельца нашего созданного пользователя:

chown vmail:vmail /home/mail

Теперь открываем на редактирование конфигурационный файл почтового сервера:

vi /etc/postfix/main.cf

И редактируем следующие строки:

mydestination = localhost.$mydomain, localhost, localhost.localdomain

...

inet_protocols = ipv4

...

smtpd_tls_cert_file = /etc/ssl/mail/public.pem

smtpd_tls_key_file = /etc/ssl/mail/private.key

* где:

• mydestination — указываем, для каких доменов принимаем входящую почту.
• inet_protocols — данный параметр задаст протокол для работы postfix. В данном примере на ipv4 — если в нашей системе не используется IPv6, могут возникнуть проблемы при маршрутизации почты. Также можно задать значения all или ipv6.
• smtpd_tls_cert_file — полный путь до публичного сертификата.
• smtpd_tls_key_file — полный путь до приватного сертификата.

Если имя сервера отличается от имени, по которому сервер будет зарегистрирован в DNS, задаем опцию:

myhostname = mx01.dmosk.ru

Теперь в конец конфигурационного файла допишем следующее:

virtual_mailbox_base = /home/mail

virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf

virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf

virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf

virtual_minimum_uid = 1024

virtual_uid_maps = static:1024

virtual_gid_maps = static:1024

virtual_transport = dovecot

dovecot_destination_recipient_limit = 1



smtpd_sasl_auth_enable = yes

smtpd_sasl_exceptions_networks = $mynetworks

smtpd_sasl_security_options = noanonymous

broken_sasl_auth_clients = yes

smtpd_sasl_type = dovecot

smtpd_sasl_path = private/auth



smtp_use_tls = yes

smtpd_use_tls = yes

smtpd_tls_auth_only = yes

smtpd_helo_required = yes

* где:

• virtual_mailbox_base — базовый путь хранения почтовых ящиков в системе UNIX.
• virtual_alias_maps — формат и путь хранения алиасов для виртуальных пользователей.
• virtual_mailbox_domains — формат и путь хранения доменов виртуальных пользователей.
• virtual_mailbox_maps — формат и путь хранения почтовых ящиков для виртуальных пользователей.
• virtual_minimum_uid — с какого номера присваивать идентификаторы пользователям.
• virtual_uid_maps — идентификатор пользователя, от которого записываются сообщения.
• virtual_gid_maps — идентификатор группы, от которой записываются сообщения.
• virtual_transport — задает доставщика сообщений.
• dovecot_destination_recipient_limit — передача сообщений от Postfix в Dovecot выполняется по заданному количеству (в нашем примере, по 1 шт.).
• smtpd_sasl_auth_enable — разрешает sasl аутентификацию.
• smtpd_sasl_exceptions_networks — исключение сетей от использования шифрования.
• smtpd_sasl_security_options — дополнительные опции настройки sasl.
• broken_sasl_auth_clients — эту опцию прописываем для клиентов MS Outlook.
• smtpd_sasl_type — указывает тип аутентификации.
• smtpd_sasl_path — путь до временных файлов обмена информацией с Dovecot. Указывается либо абсолютный путь, либо относительный queue_directory (по умолчанию /var/spool/postfix). Итого, полный путь — /var/spool/postfix/private/auth.
• smtp_use_tls — по возможности, использовать шифрованное соединение для подключение к другому серверу SMTP при отправке письма.
• smtpd_use_tls — указывает клиентам на наличие поддержки TLS.
• smtpd_tls_auth_only — использовать только TLS.
• smtpd_helo_required — требовать начинать сессию с приветствия.

Создаем файл с настройками обращения к базе с алиасами:

vi /etc/postfix/mysql_virtual_alias_maps.cf

user = postfix

password = postfix123

hosts = localhost

dbname = postfix

query = SELECT goto FROM alias WHERE address='%s' AND active = '1'

* где user и password — логин и пароль для подключения к MySQL; hosts — имя сервера баз данных (в нашем случае, локальный сервер); dbname — имя базы данных; query — шаблон запроса к данным.

Создаем файл с инструкцией получения данных по виртуальным доменам:

vi /etc/postfix/mysql_virtual_domains_maps.cf

user = postfix

password = postfix123

hosts = localhost

dbname = postfix

query = SELECT domain FROM domain WHERE domain='%u'

И файл с почтовыми ящиками:

vi /etc/postfix/mysql_virtual_mailbox_maps.cf

user = postfix

password = postfix123

hosts = localhost

dbname = postfix

query = SELECT CONCAT(domain,'/',maildir) FROM mailbox WHERE username='%s' AND active = '1'

Открываем файл master.cf и дописываем в самый конец:

vi /etc/postfix/master.cf

submission   inet  n  -  n  -  -  smtpd

  -o smtpd_tls_security_level=may

  -o smtpd_sasl_auth_enable=yes

  -o smtpd_sasl_type=dovecot

  -o smtpd_sasl_path=/var/spool/postfix/private/auth

  -o smtpd_sasl_security_options=noanonymous

  -o smtpd_sasl_local_domain=$myhostname



smtps   inet  n  -  n  -  -  smtpd

  -o syslog_name=postfix/smtps

  -o smtpd_tls_wrappermode=yes

  -o smtpd_sasl_auth_enable=yes

  -o smtpd_client_restrictions=permit_sasl_authenticated,reject



dovecot   unix  -  n  n  -  -  pipe

  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}

* необходимо убедиться, что в содержимом файла нет других раскомментированных опций для submission, smtps и dovecot (по умолчанию, их нет). В данном случае, мы настроили работу postfix на портах 25, 465 и 587. В файле master.cf мы настраиваем работу вспомогательных сервисов для Postfix. Описание каждого сервиса начинается с новой строки без отступа. Затем идут настройки для сервиса и параметры запуска. Для примера, рассмотрим первую добавленную строку — 
submission   inet  n  —  n  —  —  smtpd:

• submission — имя сервиса. Возможно использование заранее определенных в postfix служб или создание своих. В данном примере submission для подключения MUA по порту 587 при отправке почты.
• inet — тип обслуживания. Возможны варианты inet (сокет TCP/IP), unix (потоковый сокет), unix-dgram (сокет дейтаграммы), fifo (именованный канал очереди), pass (потоковый сокет UNIX-домена).
• первый «n» — является ли сервис частным и должен быть ограниченным. Возможны варианты y или n. Для типа обслуживания inet может быть только n.
• первый «-« — работает ли служба с правами root. Возможны варианты y, n и —. Прочерк означает неприменимость данного параметра к конкретному сервису.
• второй «n» — должна ли служба работать в окружении chroot. Возможны варианты y или n.
• второй «-« — через какое время в секундах пробудить службу, если она неактивна.
• третий «-» — максимальное количество одновременно выполняемых процессов, которые может запустить данный сервис.
• smtpd — выполняемая команда.

* после команды идут аргументы ее запуска. Они могут переопределять параметры, заданные в main.cf. Каждый аргумент записывается с новой строки и начинается с двух пробелов. В данном примере мы используем следующие аргументы:

• smtpd_tls_security_level — задает уровень безопасности с применением TLS. В данном примере may говорит о возможности его использования.
• smtpd_sasl_auth_enable — разрешает sasl аутентификацию.
• smtpd_sasl_type — указывает тип аутентификации.
• smtpd_sasl_path — путь до временных файлов обмена информацией с сервером хранения почты (в нашем случае Dovecot). Указывается либо абсолютный путь, либо относительный queue_directory.
• smtpd_sasl_security_options — дополнительные опции настройки sasl.
• smtpd_sasl_local_domain — добавить домен для пользователей, которые проходят smtp-аутентификацию.
• syslog_name — префикс названия службы при занесении ее в системный журнал.
• smtpd_tls_wrappermode — запускать ли службу в нестандартном режиме (для поддержки TLS).
• smtpd_client_restrictions — настройки ограничения клиентских соединений. В данном примере разрешить только авторизованных.

Генерируем сертификаты безопасности. Для этого создаем каталог, в котором их разместим:

mkdir -p /etc/ssl/mail

И сгенерируем их следующей командой:

openssl req -new -x509 -days 1461 -nodes -out /etc/ssl/mail/public.pem -keyout /etc/ssl/mail/private.key -subj "/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=relay.dmosk.ru"

* сертификат сгенерирован на 1461 день, ключи subj могут быть произвольными, CN необходимо указать в соответствии с именем сервера, по которому мы будем подключаться к почте.
* если мы хотим использовать сертификат, который будет проходить все проверки безопасности, его нужно купить или запросить у Let’s Encrypt.

Разрешаем запуск postfix:

systemctl enable postfix

Перезапускаем его:

systemctl restart postfix

5. Настройка Dovecot

Устанавливаем Dovecot с компонентом для работы с СУБД:

apt-get install dovecot-imapd dovecot-pop3d dovecot-mysql

Настраиваем способ хранения сообщений:

vi /etc/dovecot/conf.d/10-mail.conf

mail_location = maildir:/home/mail/%d/%u/

* в данном примере сообщения будут храниться в продвинутом формате maildir в каталоге /home/mail/<почтовый домен>/<логин пользователя>. 

Настраиваем слушателя для аутентификации:

vi /etc/dovecot/conf.d/10-master.conf

service auth {

  unix_listener /var/spool/postfix/private/auth {

    mode = 0666

    user = postfix

    group = postfix

  }

  unix_listener auth-userdb {

    mode = 0600

    user = vmail

    group = vmail

  }

}

* в данном примере мы настраиваем сервис для аутентификации и создаем два прослушивателя: /var/spool/postfix/private/auth — для возможности постфиксом использовать авторизацию через Dovecot (обращаем внимание, что /var/spool/postfix/private/auth — это тот же private/auth, который был прописан нами в postfix); auth-userdb — сокет для авторизации через dovecot-lda. Опция mode задает права на сокет, например, 666 позволит любому пользователю к нему подключиться; user и group задает пользователя и группу владельцев на сокет.

А также в этом файле добавим строки:

service stats {

    unix_listener stats-reader {

        user = vmail

        group = vmail

        mode = 0660

    }

    unix_listener stats-writer {

        user = vmail

        group = vmail

        mode = 0660

    }

}

* в противном случае, мы увидим в логе ошибку error net_connect_unix(/var/run/dovecot/stats-writer) failed permission denied, так как у пользователя vmail не будет прав.

Настраиваем аутентификацию в Dovecot:

vi /etc/dovecot/conf.d/10-auth.conf

#!include auth-system.conf.ext

!include auth-sql.conf.ext

* в данном случае мы просто комментируем обычную аутентификацию и снимаем комментарий для использования sql-аутентификации.

Настраиваем использование шифрования:

vi /etc/dovecot/conf.d/10-ssl.conf

ssl = required

ssl_cert = </etc/ssl/mail/public.pem

ssl_key = </etc/ssl/mail/private.key

* ssl = required укажет dovecot требовать от клиентов использования шифрования; ssl_cert — путь до открытого сертификата (также нами указывался в postfix); ssl_key — путь к закрытому ключу.

Настроим автоматическое создание каталогов при первом подключении пользователя к ящику:

vi /etc/dovecot/conf.d/15-lda.conf

lda_mailbox_autocreate = yes

Настраиваем подключение к нашей базе данных:

vi /etc/dovecot/conf.d/auth-sql.conf.ext

passdb {

  …

  args = /etc/dovecot/dovecot-sql.conf.ext

}

userdb {

  …

  args = /etc/dovecot/dovecot-sql.conf.ext

}

* в данном примере мы указали на файл, в котором будут находиться настройки для получения пользователей и паролей из базы данных. Данная настройка является настройкой по умолчанию и, в большинстве случаев, ее не нужно менять без необходимости указать свой путь.

Откроем на редактирование файл с настройками работы с mysql:

vi /etc/dovecot/dovecot-sql.conf.ext

В самый низ добавим: 

driver = mysql

connect = host=localhost dbname=postfix user=postfix password=postfix123

default_pass_scheme = MD5-CRYPT

password_query = SELECT password FROM mailbox WHERE username = '%u'

user_query = SELECT maildir, 1024 AS uid, 1024 AS gid FROM mailbox WHERE username = '%u'

user_query = SELECT CONCAT('/home/mail/',LCASE(`domain`),'/',LCASE(`maildir`)), 1024 AS uid, 1024 AS gid FROM mailbox WHERE username = '%u'

* в данном примере мы настроили запрос на получение данных из базы mysql (mariadb). password_query — запрос на получение пароля из таблицы mailbox; user_query — запрос на получение данных пользователя (домашняя почтовая директория, идентификатор 1024 (идентификатор созданного нами ранее пользователя vmail).

И, напоследок, настраиваем интерфейс, на котором будет слушать dovecot:

vi /etc/dovecot/dovecot.conf

listen = *

* по умолчанию, dovecot слушает также на ipv6 (listen = *, ::). Если на сервере не используется 6-я версия протокола TCP/IP, в логах dovecot появятся ошибки:
master: Error: service(imap-login): listen(::, 143) failed: Address family not supported by protocol
master: Error: service(imap-login): listen(::, 993) failed: Address family not supported by protocol

Разрешаем запуск dovecot:

systemctl enable dovecot

Перезапускаем dovecot:

systemctl restart dovecot

6. Создаем первый почтовый ящик и проверяем работу сервера

В браузере вводим в адресной строке путь до Postfixadmin — http://<IP-адрес сервера>/postfixadmin/public/.

Вводим логин и пароль от административной учетной записи, которую мы создали на шаге 3. Перед нами появится страница управления учетными записями.

Переходим в Список доменов — Новый домен:

Заполняем формы и нажимаем по Добавить домен:

Теперь переходим в Обзор — Создать ящик:

Вводим данные нового пользователя и нажимаем по Создать ящик:

Теперь можно подключиться к серверу с помощью любой почтовой программы, например, Mozilla Thunderbird.

Параметры для подключения:

• Сервер: имя сервера или его IP-адрес (не желательно, так как сертификат выдается по доменному имени).
• IMAP: 143 STARTTLS или 993 SSL/TLS
• POP3: 110 STARTTLS или 995 SSL/TLS
• SMTP: 25 STARTTLS или 465 SSL/TLS или 587 STARTTLS

* для корректной работы сервера на портах 993, 995, 465 (SSL/TLS) необходим правильный сертификат (для нашего домена и выпущенный доверенным центром сертификации).

7. Устанавливаем и настраиваем Roundcube Webmail

В данной инструкции мы разберем использование веб-клиента Roundcube. При необходимости, можно установить другой, например, WebMail Lite или несколько одновременно.

На официальном сайте заходим на страницу загрузки Roundcube. Смотрим ссылку на версию продукта с длительной поддержкой (LTS):

Используем ссылку, чтобы загрузить архив программы:

wget https://github.com/roundcube/roundcubemail/releases/download/1.2.11/roundcubemail-1.2.11-complete.tar.gz

Создаем каталог, где будут размещаться файлы портала:

mkdir /var/www/html/webmail

И распаковываем скачанный архив:

tar -C /var/www/html/webmail -xvf roundcubemail-*.tar.gz --strip-components 1

Копируем шаблон конфига:

cp /var/www/html/webmail/config/config.inc.php.sample /var/www/html/webmail/config/config.inc.php

И открываем его на редактирование:

vi /var/www/html/webmail/config/config.inc.php

$config['db_dsnw'] = 'mysql://roundcube:roundcube123@localhost/roundcubemail';

$config['enable_installer'] = true;

* первую строку мы редактируем, а вторую добавляем. В первой строке roundcube:roundcube123 — логин и пароль для доступа к базе данных; localhost — сервер базы данных; roundcubemail — имя базы данных. Вторая строка разрешает установку портала.

Также дописываем в конфигурационный файл следующее:

$config['drafts_mbox'] = 'Drafts';

$config['junk_mbox'] = 'Junk';

$config['sent_mbox'] = 'Sent';

$config['trash_mbox'] = 'Trash';

$config['create_default_folders'] = true;

* настройка $config[‘create_default_folders’] = true создает папки по умолчанию, если их нет:

• Drafts — Черновики.
• Junk — СПАМ.
• Sent — Отправленные.
• Trash — Корзина.

* Без данной настройки, если не создавались папки другим клиентом, веб-клиент будет выдавать ошибки при перемещении писем, например, при их удалении.

Задаем владельца apache на папку портала:

chown -R www-data:www-data /var/www/html/webmail

Создаем в MariaDB базу для roundcubemail:

mysql -uroot -p

> CREATE DATABASE roundcubemail DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

> GRANT ALL PRIVILEGES ON roundcubemail.* TO roundcube@localhost IDENTIFIED BY 'roundcube123';

> quit

И загружаем в созданную базу данные:

mysql -uroot -p roundcubemail < /var/www/html/webmail/SQL/mysql.initial.sql

Устанавливаем компоненты, необходимые для работы Roundcube:

apt-get install php-pear php-intl php-ldap php-net-smtp php-gd php-imagick php-zip

В Ubuntu нет возможности установить компонент mcrypt из репозитория — для начала установим пакеты, необходимые для сборки его их исходников:

apt-get install php-dev libmcrypt-dev

Выполняем команды:

pecl channel-update pecl.php.net

pecl install mcrypt-1.0.4

Создадим файл с настройкой нового модуля:

vi /etc/php/7.4/fpm/conf.d/99-mcrypt.ini

extension=mcrypt.so

Настроим php:

vi /etc/php/7.4/fpm/php.ini

date.timezone = "Europe/Moscow"

...

post_max_size = 30M

...

upload_max_filesize = 30M

* в данном примере мы задаем московское время и возможность загружать файл размером в 30 Мб (это будет максимальным объемом вложений, которые можно отправлять через веб-интерфейс).

Перезагружаем php-fpm:

systemctl restart php7.4-fpm

Настроим nginx:

vi /etc/nginx/nginx.conf

Добавим строку в раздел http:

http {

    ...

    client_max_body_size 30M;

    ...

* данной настройкой мы также разрешим загрузку файлов размером 30 Мб.

Перезапустим nginx для применения настройки:

systemctl restart nginx

Теперь открываем браузер и переходим по адресу http://<IP-адрес сервера>/webmail/installer/. В самом низу нажимаем по кнопке Next. Если кнопка будет неактивна, проверяем, что нет ошибок (NOT OK).

На следующей странице проверяем, что все пункты находятся в состоянии OK. Установка выполнена.

Открываем конфигурационный файл roundcube:

vi /var/www/html/webmail/config/config.inc.php

Запрещаем установку портала:

$config['enable_installer'] = false;

После удаляем папку с установочными скриптами:

rm -R /var/www/html/webmail/installer

И заходим в браузере по адресу http://<IP-адрес сервера>/webmail/. Вводим в качестве логина адрес почты созданного пользователя и его пароль.

8. Защищаемся от вирусов и СПАМа

Антивирус требует много ресурсов. Будьте готовы, что после его запуска сервер начнет работать медленнее и понадобится добавить ресурсы.

Установка и настройка Clamav + Amavisd

Устанавливаем необходимые для работы антивируса и антиспама компоненты:

apt-get install amavisd-new clamav clamav-daemon spamassassin

Добавляем пользователя clamav в группу amavis:

usermod -a -G amavis clamav

Открываем конфигурационный файл amavis:

vi /etc/amavis/conf.d/15-content_filter_mode

Снимаем комментарии для строк:

...

@bypass_virus_checks_maps = (

   %bypass_virus_checks, @bypass_virus_checks_acl, $bypass_virus_checks_re);

...

@bypass_spam_checks_maps = (

   %bypass_spam_checks, @bypass_spam_checks_acl, $bypass_spam_checks_re);

...

* по умолчанию amavis не выполняем никаких проверок — для включения сканирования на вирусы снимаем комментарий с bypass_virus_checks_maps, а для сканирования на СПАМ — bypass_spam_checks_maps.

Затем открываем на редактирование:

vi /etc/amavis/conf.d/50-user

Добавим строки:

$allowed_header_tests{'multiple'} = 0;

$allowed_header_tests{'missing'} = 0;

* данные опции позволят программе Outlook без ошибок отправлять тестовое сообщение.

Разрешаем запуск антивируса и amavis:

systemctl enable clamav-daemon clamav-freshclam amavis

Перезапускаем сервисы:

systemctl restart amavis clamav-daemon clamav-freshclam

Настройка Postfix

Добавляем в postfix:

vi /etc/postfix/main.cf

content_filter = scan:[127.0.0.1]:10024

* где content_filter указывает на приложение, которое будет сканировать сообщения;

Теперь редактируем master.cf:

vi /etc/postfix/master.cf

Дописываем следующее:

scan   unix  -  -  n  -  16  smtp

  -o smtp_send_xforward_command=yes

  -o smtp_enforce_tls=no



127.0.0.1:10025   inet  n  -  n  -  16  smtpd

  -o content_filter=

  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks

  -o smtpd_helo_restrictions=

  -o smtpd_client_restrictions=

  -o smtpd_sender_restrictions=

  -o smtpd_recipient_restrictions=permit_mynetworks,reject

  -o mynetworks_style=host

  -o smtpd_authorized_xforward_hosts=127.0.0.0/8

* итак, данной настройкой мы создадим два вспомогательных сервиса scan и 127.0.0.1:10025 (сервис без имени, он просто будет слушать на порту 10025 — это порт по умолчанию, на который отправляет сообщение amavis после выполнения проверки). Также, мы используем следующие опции:

• smtp_send_xforward_command — передавать ли в сканирование сообщение с исходными именем клиента и IP-адресом. В данном примере, да.
• smtp_enforce_tls — требовать ли TLS.
• content_filter — приложение для сканирования. В данном примере сканирование отключено.
• receive_override_options переопределяет опции в main.cf. В нашем случае, no_unknown_recipient_checks отключает попытки выяснить, является ли получатель неизвестным; no_header_body_checks отключает проверки заголовков и тала писем.
• пустые значения для smtpd_helo_restrictions, smtpd_client_restrictions, smtpd_sender_restrictions отключают ограничения для данных опций.
• smtpd_recipient_restrictions — контролирует ответ Postfix на SMTP-команду RCPT TO. Здесь мы разрешаем только соединения от узлов, перечисленных в mynetworks.
• mynetworks_style=host указывает postfix, что он должен пересылать почту только с локального компьютера.
• smtpd_authorized_xforward_hosts укажет, какие удаленные клиенты могут использовать XFORWARD. В данном случае локальный компьютер.

Перезапускаем postfix:

systemctl restart postfix

Настройка обновлений антиспама

Для обновления базы антиспама выполняем команду:

sa-update --nogpg --verbose

Для настройки автоматического обновления, редактируем cron:

crontab -e

30 3 * * * /usr/bin/sa-update

* в данном примере, каждый день в 03:30 будет запускаться процесс обновления антиспама.

Проверка

Для проверки антивируса отправляем сообщение со следующим содержимым:

X5O!P%@AP[4PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Большинство почтовых систем экранинуют вирусную последовательность и письмо нормально пройдет мимо нашего антивируса. Чтобы сделать корректный тест, необходимо отправить письмо SMTP-командами.

Письмо не должно дойти, а в логе (/var/log/maillog) мы увидим строку:

... amavis[17688]: (17688-04) Blocked INFECTED (Eicar-Signature) {DiscardedOutbound,Quarantined}, MYNETS LOCAL ...

... relay=127.0.0.1[127.0.0.1]:10024, delay=0.25, delays=0.19/0/0/0.06, dsn=2.7.0, status=sent (250 2.7.0 Ok, discarded, id=17688-04 - INFECTED: Eicar-Signature)

Для проверки работы контентного антиспама, отправляем письмо со следующим содержимым:

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

В итоге, письмо не должно прийти, а в логах мы увидим:

... amavis[17689]: (17689-04) Blocked SPAM {DiscardedOutbound,Quarantined}, MYNETS LOCAL ...

... status=sent (250 2.7.0 Ok, discarded, id=17689-04 - spam)

Пересылка СПАМа и вирусов на другой ящик

Все письма со спамом и вирусами будут перемещаться в карантин. Если мы хотим перенаправлять все подобные сообщения на специальный ящик, то необходимо настроить amavis.

Открываем конфигурационный файл:

vi /etc/amavis/conf.d/50-user

Добавляем такие опции:

$spam_quarantine_to = "spam@dmosk.ru";

$virus_quarantine_to = "virus@dmosk.ru";

* где $spam_quarantine_to указываем на адрес для перенаправления СПАМ-писем; $virus_quarantine_to — почта для писем с обнаруженными вирусами.

После перезагрузим amavis:

systemctl restart amavis

Пробуем отправить сообщения с тестовыми сигнатурами на СПАМ и вирус — письма должны быть перенаправлены на указанные адреса.

Антиспам средствами Postfix

В MTA Postfix встроен свой механизм проверки заголовков входящих сообщений. Правила размещаются в 7 секций, обработка которых выполняется в следующем порядке:

client -> helo -> sender -> relay -> recipient -> data -> end_of_data

Чтобы лучше понять принцип, мы должны знать SMTP-команды при выполнении отправки почты. И так, порядок, следующий:

1. Соединение с сервером.
2. Команда HELO. Приветствие, в котором отправитель называет свое имя, по которому можно проверить, соответствует ли оно правилам именования и своему IP-адресу.
3. MAIL FROM — указывает адрес отправителя. Выполняется для sender и relay.
4. RCPT TO — кому отправляем письмо.
5. DATA — команда сообщает о готовности отправить письмо с заголовками и текстом.
6. END-OF-DATA — отправка письма.

И так, для настройки антиспама открываем конфигурационный файл main.cf:

vi /etc/postfix/main.cf

Комментируем строку:

#smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

И добавляем:

smtpd_client_restrictions =

        permit_mynetworks

        permit_sasl_authenticated

        reject_unauth_pipelining

        permit



smtpd_helo_restrictions =

        permit



smtpd_sender_restrictions =

        permit_mynetworks

        permit_sasl_authenticated

        reject_non_fqdn_sender

        reject_unknown_sender_domain

        permit



smtpd_relay_restrictions =

        permit_mynetworks

        permit_sasl_authenticated

        defer_unauth_destination



smtpd_recipient_restrictions =

        permit_mynetworks

        permit_sasl_authenticated

        reject_non_fqdn_recipient

        reject_unauth_destination

        reject_unknown_recipient_domain

        reject_unverified_recipient

        permit



smtpd_data_restrictions =

        permit



smtpd_end_of_data_restrictions =

        permit

* где параметры:

1. smtpd_client_restrictions — настройки ограничений при осуществлении клиентских соединений с почтовым сервером.
2. smtpd_helo_restrictions — ограничения в контексте клиентской команды HELO.
3. smtpd_sender_restrictions — ограничения будут применяться во время выполнения клиентской команды MAIL FROM.
4. smtpd_relay_restrictions — ограничения пересылки почты в контексте клиентской команды RCPT TO.
5. smtpd_recipient_restrictions — ограничения в контексте клиентской команды RCPT TO после пересылки (smtpd_relay_restrictions).
6. smtpd_data_restrictions — ограничения будут применяться во время выполнения команды DATA.
7. smtpd_end_of_data_restrictions — ограничения во вреся выполнения команды END-OF-DATA.

… и значения для них:

• permit_mynetworks — разрешает все адреса, перечисленные в настройке mynetworks.
• permit_sasl_authenticated — разрешает запросы всех успешно авторизованных клиентов.
• reject_unauth_pipelining — запрещает отправку писем, которые отправляются заранее (пропуская правильную цепочку сессии SMTP).
• reject_non_fqdn_sender — отклонить соединение, если адрес отправителя указан неправильно (согласно RFC).
• reject_unknown_sender_domain — запрещает запрос, если Postfix не является конечным пунктом назначения для адреса отправителя, а домен MAIL FROM не имеет 1) DNS-записи MX и DNS-записи A или 2) искаженной MX-записи, такой как запись с MX-именем хоста нулевой длины.
• reject_non_fqdn_recipient — запретить соединение, если адрес получателя указан неправильно (согласно RFC).
• reject_unauth_destination — отклонить соединение, если письмо не пересылается согласно правилу relay_domains или сервер не является адресом назначения. Другими словами, запрещает использование нашего сервера в качестве open relay.
• reject_unknown_recipient_domain — отклонить запрос, если Postfix не является конечным пунктом назначения для домена получателя, а домен RCPT TO не имеет 1) DNS-записи MX и DNS-записи A или 2) неверно сформированной MX-записи, такой как запись с именем хоста MX нулевой длины.
• reject_unverified_recipient — отклонить запрос, если известно, что почта на адрес RCPT TO отклоняется или когда адрес получателя не доступен. 
• permit — разрешает соединение. Ставим в конец каждого блока ограничений (если ограничения не сработали, то разрешаем).

* это более или менее мягкие правила. Их можно использовать первое время, пока тестируем сервер.

Для усиления защиты добавляем:

smtpd_recipient_restrictions =

        ...

        reject_unknown_client_hostname

        reject_invalid_helo_hostname

        reject_non_fqdn_helo_hostname

        reject_unknown_helo_hostname

        reject_rbl_client bl.spamcop.net

        reject_rbl_client cbl.abuseat.org

        reject_rbl_client dul.ru

        reject_rbl_client dnsbl.abuse.ch

        permit

* где:

• reject_unknown_client_hostname — проверяет наличие PRT-записи отправителя и наличие рабочей А-записи в соответствие PTR.
• reject_invalid_helo_hostname — проверяет синтаксис HELO-приветствия.
• reject_non_fqdn_helo_hostname — требует правильного FQDN-имени во время HELO-приветствия.
• reject_unknown_helo_hostname — запрещает представляться именами, для которых нет А-записи или MX.
• reject_rbl_client — проверяет наличие отправителя в черных списках.

* более подробное описание опций для защиты можно найти на странице postfix.org/postconf.5.html.

После внесения всех правок, необходима перезагрузка Postfix:

systemctl restart postfix

Обучение антиспама

Мы установили amavis, который проверяет почту на СПАМ средствами spamassassin. Последний без обучения, практически, бесполезен. Синтаксис команды для обучения следующий:

sa-learn --spam <папка с нежелательными письмами>

sa-learn --ham <папка письмами, которые ошибочно определены как СПАМ>

Таким образом, первая команда укажет spamassassin какие письма являются нежелательными, а вторая — не несущими рекламный характер.

Хорошей практикой будет договориться с пользователями о ручном помещении нежелательной почты из входящих в папку СПАМ. Тогда мы сможем пройтись скриптом по всем ящикам на сервере и обучать антиспам. Например, такой командой:

sa-learn --spam /home/mail/dmosk.local/*/{.&BCEEPwQwBDw-,.Spam,.Junk E-mail,.Junk}/cur

* в данном примере мы сказали spamassassin найти в каталогах пользователей папки Спам, Spam, Junk, Junk E-mail (данные каталоги являются типичными для помещения СПАМа) и провести обучение. 

Чтобы минимизировать количество ложных срабатываний, необходимо проводить обучение с ключом —ham. В нашем примере мы отправляем все нежелательные письма на ящик spam. В таком случае, необходимо вручную находить ложные срабатывания и переносить их в специальную папку, например Ham. Тогда команда для обучения будет такой:

sa-learn --ham /home/mail/dmosk.local/spam@dmosk.local/.Ham/cur

Статистику обучения можно посмотреть командой:

sa-learn --dump magic

9. Отправка почты наружу

Для отправки почты на другие почтовые серверы необходимо правильно сконфигурировать сервер, чтобы письма не попадали в СПАМ. Чтобы это сделать, выполняем инструкции ниже.

Настройки DNS для сервера

Многие почтовые серверы делают запросы в систему доменных имен для проверки легитимности почтового сервера, отправляющего почту. При настройке MTA очень важно правильно добавить необходимые записи в DNS.

1. rDNS. Обратная зона используется для проверки соответствия имени сервера в приветствии с именем, которое возвращает NS сервер при запросе по PTR-записи.

И так, для создания записи в обратной зоне, необходимо написать письмо Интернет провайдеру, к сети которого подключен сервер или хостеру, если почтовый сервер настроен на VPS. IP-адрес нашего сервера должен вести на имя, которым приветствуется наш postfix — можно посмотреть командой:

postconf -n smtpd_banner

Если мы получим пустой ответ, то вводим:

postconf -n myhostname

Если и в этот вариант не вернет ответ, вводим:

hostname

2. А-запись. Также необходимо, чтобы имя сервера, которым представляется почтовый сервер разрешалось в IP-адрес.

Для этого заходим в консоль управления зоной нашего домена и создаем запись типа А для сопоставления имени сервера с IP-адресом, на котором слушает запросы данный сервер.

Настройки DNS для домена

Для каждого домена, для которого будем отправлять почту создаем записи:

1. SPF.
2. DMARC.
3. DKIM

Для проверки корректности настройки сервера, воспользуемся ресурсами:

• https://www.mail-tester.com
• https://spamtest.smtp.bz

10. Настройка DKIM

Подпись писем не является обязательной, но помогает не попадать в СПАМ. DKIM настраивается для каждого домена, а также должна создаваться специальная запись в DNS. Рассмотрим создание и настройку DKIM в amavisd.

Создаем каталог для хранения ключей:

mkdir -p /var/lib/dkim

Генерируем последовательность для нашего домена:

amavisd-new genrsa /var/lib/dkim/dmosk.ru.pem 1024

* где dmosk.ru — домен, для которого мы сгенерируем подпись dkim.

Задаем права на созданный файл:

chown amavis:amavis /var/lib/dkim/*.pem

chmod 0400 /var/lib/dkim/*.pem

Открываем конфигурационный файл amavisd:

vi /etc/amavis/conf.d/20-debian_defaults

Редактируем запись:

#$inet_socket_port = 10024;

$inet_socket_port = [10024,10026];

* в данном примере мы закомментировали первую строку и раскомментировали вторую. Это укажет amavis, что он должен запускаться и работать на двух портах.

А также добавим:

$forward_method = 'smtp:[127.0.0.1]:10025';

$notify_method = $forward_method;

$interface_policy{'10026'} = 'ORIGINATING';

$policy_bank{'ORIGINATING'} = {

    originating => 1,

    smtpd_discard_ehlo_keywords => ['8BITMIME'],

    os_fingerprint_method => undef,

    bypass_banned_checks_maps => [1],

    bypass_header_checks_maps => [1],

    bypass_banned_checks_maps => [1],

    virus_admin_maps => ["virusalert@$mydomain"],

};

Открываем файл:

vi /etc/amavis/conf.d/50-user

Добавляем записи:

$enable_dkim_verification = 1;

$enable_dkim_signing = 1;



dkim_key('dmosk.ru', "dkim", "/var/lib/dkim/dmosk.ru.pem");



@dkim_signature_options_bysender_maps = ( {

   "dmosk.ru" => { d => "dmosk.ru", a => 'rsa-sha256', ttl => 10*24*3600 },

});

* где dmosk.ru — домен, для которого мы настраиваем dkim; /var/lib/dkim/dmosk.ru.pem — путь до сгенерированного файла с последовательностью.

Перезапускаем amavis:

systemctl restart amavis

Посмотреть DKIM последовательность для нового домена можно командой:

amavisd-new showkeys

Мы должны увидеть что-то на подобие:

; key#1 1024 bits, i=dkim, d=dmosk.ru, /var/lib/dkim/dmosk.ru.pem

dkim._domainkey.dmosk.ru.        3600 TXT (

  "v=DKIM1; p="

  "MIGfMA0SDFqGSIb3DQEBAQUAA4GNADCBiQKBgQC44iOK+99mYBxsnIl1Co8n/Oeg"

  "4+x90sxqWzoGW42d/GCP4wiYqVqncc37a2S5Berv0OdoCGcmkDkKWh4CHhFD4blk"

  "x6eMYXsp1unAdo2mk/OVK7M2ApraIkh1jVbGBZrREVZYTE+uPOwtAbXEeRLG/Vz5"

  "zyQuIpwY2Nx3IgEMgwIDAQAB")

Теперь нам нужно на основе данного вывода создать в DNS запись TXT. В данном примере, нужно создать запись c именем dkim._domainkey в зоне dmosk.ru и значением «v=DKIM1; p=MIGfMA0SD…wIDAQAB».

Проверить корректность настройки DKIM можно командой:

amavisd-new testkeys

Переходим к настройке Postfix. Мы должны добавить отправку всех исходящих писем на проверку в amavis на порт 10026 и принимать обратно письма на порт 10027.

Открываем файл:

vi /etc/postfix/master.cf

Отредактируем submission и smtps, добавив content_filter:

smtp      inet  n       -       y       -       -       smtpd

  -o content_filter=scan:[127.0.0.1]:10026

  ...



submission   inet  n  -  n  -  -  smtpd

  -o content_filter=scan:[127.0.0.1]:10026

  ...



smtps   inet  n  -  n  -  -  smtpd

  -o content_filter=scan:[127.0.0.1]:10026

  ...

И добавим:

127.0.0.1:10027   inet  n  -  n  -  16  smtpd

  -o content_filter=

  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks

  -o smtpd_helo_restrictions=

  -o smtpd_client_restrictions=

  -o smtpd_sender_restrictions=

  -o smtpd_recipient_restrictions=permit_mynetworks,reject

  -o mynetworks_style=host

  -o smtpd_authorized_xforward_hosts=127.0.0.0/8

Перезапускаем postfix:

systemctl restart postfix

Настраиваем Roundcube:

vi /var/www/html/webmail/config/config.inc.php

Находим строки:

$config['smtp_server'] = '';

...

$config['smtp_port'] = 25;

… и меняем ее на:

$config['smtp_server'] = 'tls://localhost';

...

$config['smtp_port'] = 587;

* в данном примере мы указали, что соединение для отправки почты должно быть защищенным. Это важно для нашей настройки DKIM.

Пробуем отправить письмо — в заголовках мы должны увидеть:

dkim=pass header.d=dmosk.ru 

11. Настройка квот

В PostfixAdmin у нас есть возможность задать квоты на почтовые ящики, но они работать не будут, так как о них ничего не знает Dovecot.

Процесс настройки не сложен и описан отдельно в статье Настройка квот в Dovecot + PostfixAdmin.

После применения квот мы сможем наблюдать в почтовом клиенте Roundcube информацию об оставшемся дисковом пространстве:

… или в Webmail Lite:

12. Автоматическая настройка почтовых клиентов

Для автоматического конфигурирования почтовых клиентов необходимо настроить сервис autodiscover. Для этого настраиваем веб-сервер, который будет возвращать почтовые настройки для домена.

Подробнее процесс настройки описан в статье Настройка Autodiscover для своего почтового сервера.

13. Папки на русском в Outlook

По умолчанию, все почтовые клиенты, кроме Outlook распознают служебные папки IMAP:

• Drafts — черновики.
• Junk — СПАМ.
• Sent — отправленные.
• Trash — удаленные.

Данные каталоги переводятся на русский язык и корректно отображаются в клиенте. В Outlook эти папки отображаются как есть — на английском языке.

Для решения проблемы мы должны открыть файл:

vi /etc/dovecot/conf.d/15-mailboxes.conf

Найти блок настроек namespace inbox. Для каждого из служебного каталога настроить следующее:

namespace inbox {

  ...

  mailbox Черновики {

    auto = subscribe

    special_use = Drafts

  }

  mailbox Drafts {

    auto = no

    special_use = Drafts

  }



  mailbox Спам {

    auto = subscribe

    special_use = Junk

  }

  mailbox Junk {

    auto = no

    special_use = Junk

  }

  mailbox Spam {

    auto = no

    special_use = Junk

  }

  mailbox "Junk E-mail" {

    auto = no

    special_use = Junk

  }



  mailbox Удаленные {

    auto = subscribe

    special_use = Trash

  }

  mailbox Trash {

    auto = no

    special_use = Trash

  }

  mailbox "Deleted Messages" {

    auto = no

    special_use = Trash

  }



  mailbox Отправленные {

    auto = subscribe

    special_use = Sent

  }

  mailbox Sent {

    auto = no

    special_use = Sent

  }

  mailbox "Sent Messages" {

    auto = no

    special_use = Sent

  }

  mailbox "Sent Items" {

    auto = no

    special_use = Sent

  }

  ..

}

* и так, мы задали несколько вариантов служебных каталогов:

• Черновики — на сервере могут быть папки Черновики и Drafts. По умолчанию отображается и создается Черновики.
• Спам — на сервере Спам, Junk, Spam, Junk E-mail.
• Удаленные — на сервере Удаленные, Trash, Deleted Messages.
• Отправленные — на сервере Отправленные, Sent, Sent Messages, Sent Items.

Для применения настроек перезапускаем dovecot:

systemctl restart dovecot

14. Разное

Рассмотрим дополнительные настройки для нашего сервера.

Настройка ограничений

Также важно настроить некоторые ограничения, например:

• максимальный размер вложения.
• количество сообщений, которое можно отправить за определенный период времени.
• настройка очереди (время хранения писем).
• таймауты отправки.

Подробнее, информацию можно найти в статье Лимиты в Postfix.

Смена email адреса

Предположим, мы сделали ошибку в написании адреса электронной почты, но не хотим удалять учетную запись и создавать ее по новой. Рассмотрим смену email-адреса на примере sekretar@dmosk.ru -> secretar@dmosk.ru.

Нам нужно внести изменения в базу данных — для этого заходим в оболочку sql:

mysql -uroot -p

Вводим пароль, который создавали после установки СУБД.

Используем базу postfix:

> use postfix

Редактируем алиасы командой:

> UPDATE alias SET `address`='secretar@dmosk.ru', `goto`=REPLACE(`goto`, 'sekretar@dmosk.ru', 'secretar@dmosk.ru') WHERE `address`='sekretar@dmosk.ru';

Редактируем почтовый ящик:

> UPDATE mailbox SET `username`='secretar@dmosk.ru', `local_part`='secretar', `maildir`=REPLACE(`maildir`, '/sekretar/', '/secretar/') WHERE `username`='sekretar@dmosk.ru';

И квоту:

> UPDATE quota2 SET `username`='secretar@dmosk.ru' WHERE `username`='sekretar@dmosk.ru';

С базой данных закончили — выходим из sql:

> quit

Переходим в каталог с почтовыми ящиками пользователей для нашего домена:

cd /home/mail/dmosk.ru/

Перемещаем папку с почтой старого ящика в новый:

mv sekretar@dmosk.ru secretar@dmosk.ru

Проверяем работу через веб-интерфейс. Если используем почтовый клиент, меняем настройки для использования нового email-адреса.

Источник: https://www.dmosk.ru/instruktions.php?object=mailserver-ubuntu

Рассмотрим процесс установки и настройки веб-инструмента жизненного цикла DevOps на Linux Ubuntu Server на примере версий 18.04 и 20.04. За основу взята официальная инструкция с сайта GitLab. В нашей инструкции приведен пример установки как платной. так и бесплатной версий программы.

Подготовка сервера

В качестве предварительный настроек, мы обновим список пакетов в репозиториях, настроим правильное время и откроем порты в брандмауэре.

1. Обновление списков пакетов

Выполняем команду:

apt-get update

При желании обновить установленные пакеты, также можно выполнить:

apt-get upgrade

2. Время

Установим часовой пояс:

timedatectl set-timezone Europe/Moscow

* данная команда задаст настройки для московского времени. Все файлы с временными зонами находятся в каталоге /usr/share/zoneinfo.

Для автоматической синхронизации времени ставим пакет:

apt-get install chrony

И разрешаем автозапуск сервиса:

systemctl enable chrony

3. Настройка брандмауэра

По умолчанию, в Ubuntu брандмауэр настроен на то, чтобы принимать любые пакеты. Но если у нас он настроен на блокировку, нужно добавить порты 80 и 443.

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

iptables -A INPUT -p tcp --dport 443 -j ACCEPT 

И чтобы сохранить правила, устанавливаем iptables-persistent:

apt-get install iptables-persistent

… и выполняем команду: 

netfilter-persistent save

Установка GitLab

Установку выполним в два шага — установка необходимых компонентов и, собственно, установка GitLab.

1. Необходимые компоненты

apt-get install curl openssh-server ca-certificates

Для отправки уведомлений, установим также postfix:

apt-get install postfix

При запросе типа конфигурации, выбираем Internet Site (если уведомления должны отправляться наружу) или Local only (уведомления в пределах сервера):

* при получении других запросов во время установки postfix можно ответить по умолчанию, нажимая Enter.

2. Установка GitLab

Установим репозиторий.

а) для платной версии:

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

б) для бесплатной:

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

После установки репозитория, устанавливаем сам GitLab.

а) платную версию:

apt-get install gitlab-ee

б) бесплатную:

apt-get install gitlab-ce

Если установка прошла успешно, мы должны увидеть:

It looks like GitLab has not been configured yet; skipping the upgrade script.
       *.                  *.

      ***                 ***

     *****               *****

    .******             *******

    ********            ********

   ,,,,,,,,,***********,,,,,,,,,

  ,,,,,,,,,,,*********,,,,,,,,,,,

  .,,,,,,,,,,,*******,,,,,,,,,,,,

      ,,,,,,,,,*****,,,,,,,,,.

         ,,,,,,,****,,,,,,

            .,,,***,,,,

                ,*,.

  



     _______ __  __          __

    / ____(_) /_/ /   ____ _/ /_

   / / __/ / __/ /   / __ `/ __ 

  / /_/ / / /_/ /___/ /_/ / /_/ /

  ____/_/__/_____/__,_/_.___/

  
Thank you for installing GitLab!

3. Конфигурируем веб-адрес

Для запуска и корректной работы портала мы должны задать external_url. Для этого открываем файл:

vi /etc/gitlab/gitlab.rb

Нам нужно только изменить параметр external_url:

external_url 'http://gitlab.dmosk.ru'

* данная настройка говорит, что наш веб-инструмент будет отвечать на запросы, которые пришли на узел gitlab.dmosk.ru — это значит, что данное имя должно быть зарегистрирована в DNS или прописано в локальный файл hosts.

Выполняем конфигурирование:

gitlab-ctl reconfigure

Данная операция займет какое-то время.

Вход в веб-интерфейс

Открываем браузер и вводим наш адрес, который мы указали в настройках в опции external_url — в данном примере, http://gitlab.dmosk.ru. Мы должны увидеть страницу авторизации, на которой нас запросят сменить пароль для администратора. Вводим его дважды:

После система попросит ввести логин и пароль — вводим логин root и пароль, который только-что придумали.

Настройка GitLab

Приведем некоторые примеры настроек, которые могут оказаться полезными.

Русский интерфейс

По умолчанию, портал устанавливается с интерфейсом на английском. Для смены языка, кликаем по иконке в правом верхнем углу и выбираем Settings:

В меню слева нажимаем по Preferences:

В подразделе Localization выбираем нужный нам язык и первый день недели:

Сохранияем настройки и перезапускаем страницу для применения нового языка.

Создание репозитория и подключение к нему

Попробуем создать проект и подключиться к нему из Linux. Также для теста мы создадим файл и закинем его в наш репозиторий.

В веб-интерфейсе GitLab создаем новый проект:

Задаем имя проекта, оставляем или редактируем URL, выбираем уровень доступа. После кликаем по кнопке Создать проект:

* в данном примере мы создаем проект с названием Test, url до него будет http://gitlab.dmosk.ru/root/test. Уровень доступа мы задаем «Приватный» — доступ к репозиторию будет только у авторизованного пользователя.

Для примера попробуем подключиться с компьютера Linux к нашему репозиторию и закинуть на него тестовый файл.

Для начала установим git на компьютер с Linux:

а) Если используем CentOS / Red Hat:

yum install git-core

б) Если используем Ubuntu / Debian:

apt-get install git

Создаем папку для тестового проекта:

mkdir -p /projects/test

Переходим в нее:

cd /projects/test

Создаем репозиторий:

git init

Создаем файл:

vi testfile.txt

Добавляем в него все файлы (то есть, наш единственный файл):

git add .

Делаем коммит:

git commit -m "Очередное изменение проекта" -a

Подключаемся к созданному репозиторию:

git remote add origin http://gitlab.dmosk.ru/root/test.git

Заливаем в него закоммиченный файл:

git push origin master

Переходим на веб-страницу нашего проекта — мы должны увидеть наш файл:

Настройка SSL

В данном примере мы сконфигурируем наш сервер для возможности работы по https и получения сертификата от Let’s Encrypt. Все настройки выполняются в конфигурационном файле:

vi /etc/gitlab/gitlab.rb

Меняем настройку:

external_url 'http://gitlab.dmosk.ru'

* где gitlab.dmosk.ru — url для нашего портала, который мы задали при первом конфигурировании.

на:

external_url 'https://gitlab.dmosk.ru'

* мы просто добавили s к http.

Также настраиваем получение сертификата от Let’s Encrypt:

letsencrypt['enable'] = true

И задаем опции для автоматического обновления сертификата:

letsencrypt['auto_renew'] = true

letsencrypt['auto_renew_hour'] = "22"

letsencrypt['auto_renew_minute'] = "50"

letsencrypt['auto_renew_day_of_month'] = "*/7"

* где:

• auto_renew — разрешает автоматическое обновление.
• auto_renew_hour — время в часах, когда нужно запускать задание на обновление сертификата.
• auto_renew_minute — время в минутах, когда нужно запускать задание на обновление сертификата.
• auto_renew_day_of_month — день месяца. В данном примере, раз в 7 дней.

Применяем новую конфигурацию:

gitlab-ctl reconfigure

В процессе переконфигурирования мы можем получить ошибку получения сертификата. Пробуем запустить команду:

gitlab-ctl renew-le-certs

Сброс пароля root

 Если мы забыли пароль для пользователя root, можно его сбросить через командную строку.

Подключаемся к консоли управления gitlab с помощью команды:

gitlab-rails console -e production

Создаем переменную, которая будет вести на ссылку с учетной записью root (идентификатор 1):

user = User.where(id: 1).first

Задаем пароль для пользователя root дважды:

user.password = 'password123'

user.password_confirmation = 'password123'

где password123 — созданный для пользователя root новый пароль.

Созраняем изменения для пользователя:

user.save!

Готово.

Источник: https://www.dmosk.ru/miniinstruktions.php?mini=gitlab-ubuntu