На предприятии с большим количеством компьютеров на базе ОС Apple macOS может возникнуть необходимость развёртывания централизованного сервера для хранения резервных копий на базе пакета Time Machine с интеграцией в механизмы доменной авторизации на базе каталога Active Directory (AD). В данной заметке мы рассмотрим три варианта организации сетевого ресурса (SMB) под задачу резервного копирования компьютеров macOS, а также поговорим о разных вариантах настройки клиентов macOS для подключения к такому ресурсу.
Сразу стоит отметить, что по причине появления Apple File System (APFS) протокол Apple Filling Protocol (AFP) стал считаться устаревшим, поэтому рассматривать AFP в контексте данной заметки мы не будем.
Организация сетевого ресурса для Time Machine на macOS
С тех пор, как Apple отказались развивать "серверные" продукты в пакете Server.app оставив только Profile manager, многие стали задаваться вопросом, а как же сейчас организовывать Time Machine Server?
На мой взгляд, Apple сделали лучше, чем было ранее, потому что перенесли возможность организации сетевого хранения резервных копий macOS в базовые настройки ОС, и поэтому теперь не требуется ничего устанавливать дополнительно.
Рассмотрим пример создания сетевого каталога для Time Machine на macOS Mojave.
1. Откроем настройки и перейдём в общий доступ;
2. Добавим каталог, который будет использоваться для Time Machine;
3. Вызываем контекстное меню на каталоге и откроем "дополнительные параметры…"
Разрешим использовать каталог для резервного копирования Time Machine.
Если macOS введён в домен, то на каталог можно применить необходимую группу безопасности AD для ограничения доступа к резервным копиям.
Общие ресурсы для Time Machine не поддерживаются на разделах APFS.
Организация сетевого ресурса для Time Machine на Linux Debian 10
Поддержка Apple Time Machine появилась в Samba 4.8, но в репозитории Debian 9 имеется только версия 4.5, поэтому необходимо либо собирать Samba в ручную, либо установить пред-релизную сборку Debian 10 Buster, в репозитория которого Samba 4.9.5.
В нашем примере на базе хоста виртуализации с Windows Server 2012 R2 разворачивается виртуальная машина Hyper-V Gen2 c гостевой ОС Debian 10 Buster. Описанная далее процедура базовой настройки Debian 10 не имеет прямого отношения к нашей задаче резервного копирования и добавлена для полноты описания. Поэтому знатоки Debian могут переместиться в конец этого раздела, где идёт речь о создании сетевого ресурса на базе Samba.
Итак, выполним вход под супер-пользователем и начнём настраивать систему.
Первым делом необходимо настроить сеть:
# nano /etc/network/interfaces
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 10.28.35.20/24
gateway 10.28.35.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 10.10.0.2 10.20.0.2
dns-search holding.com
Если в сети не используется IPv6, то отключим его:
# nano /etc/sysctl.conf
...
# Turn off IPv6
#
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
Применим изменения:
# sysctl -p
Если для доступа в Интернет используется прокси-сервер, настроим его, чтобы была возможность устанавливать и обновлять пакеты:
# nano /etc/profile
...
#Set proxy
#
export ALL_PROXY=http://s-Update-User:P2ssw0rd@KOM-PROXY.holding.com:3128
export http_proxy=$ALL_PROXY
export https_proxy=$ALL_PROXY
export ftp_proxy=$ALL_PROXY
Применяем изменения:
# source /etc/profile
Настоим репозитории Debian 10:
# nano /etc/apt/sources.list
...
#
deb http://deb.debian.org/debian buster main contrib non-free
deb-src http://deb.debian.org/debian buster main contrib non-free
#
deb http://deb.debian.org/debian buster-updates main contrib non-free
deb-src http://deb.debian.org/debian buster-updates main contrib non-free
#
deb http://security.debian.org/ buster/updates main contrib non-free
deb-src http://security.debian.org/ buster/updates main contrib non-free
Установим обновления пакетов:
# apt-get update
# apt-get upgrade
Установим пакеты, необходимые в рамках нашей задачи:
# apt-get install hyperv-daemons ntp sssd krb5-user policykit-1 packagekit samba sudo net-tools
Настроим sudo, разрешив всем пользователям повышающим привилегии, использовать ранее заданные переменные с настройками прокси:
# visudo
Defaults env_keep = "http_proxy https_proxy ftp_proxy"
Разрешим пользователю user1 выполнять повышение привилегий. Добавим пользователя user1 в группу sudo
# usermod -aG sudo user1
Теперь можно завершить сеанс пользователя root и в дальнейшем пользоваться учётной записью user1.
Так как система будет добавлена в домен, необходимо, чтобы на нашем сервере с Debian 10 было правильное время. Настроим NTP-клиент на получение времени с контроллеров домена:
$ sudo nano /etc/ntp.conf
Добавляем в файл записи о NTP-серверах:
...
server dc01.holding.com
server dc02.holding.com
...
Перезапускаем службу
$ sudo systemctl restart ntp
Настраиваем поддержку Kerberos под свой домен AD:
$ sudo mv /etc/krb5.conf /etc/krb5.conf.org
$ sudo nano /etc/krb5.conf
[libdefaults]
dns_lookup_kdc = no
dns_lookup_realm = no
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = HOLDING.COM
# for Windows 2008 with AES
default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
[realms]
HOLDING.COM = {
kdc = dc01.holding.com
kdc = dc02.holding.com
admin_server = dc01.holding.com
default_domain = holding.com
}
[domain_realm]
.holding.com = HOLDING.COM
holding.com = HOLDING.COM
Настраиваем конфигурацию SSSD под свой домен AD:
$ sudo nano /etc/sssd/sssd.conf
[sssd]
domains = holding.com
config_file_version = 2
services = nss, pam
default_domain_suffix = holding.com
[domain/holding.com]
ad_server = dc01.holding.com, dc02.holding.com
ad_backup_server = dc03.holding.com, dc04.holding.com
ad_domain = holding.com
ad_gpo_access_control = disabled
krb5_realm = HOLDING.COM
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
ldap_idmap_default_domain_sid = S-1-5-21-3456789012-5678989012-6654389012
ldap_idmap_range_size = 2000000
ldap_use_tokengroups = False
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
access_provider = ad
subdomains_provider = none
default_shell = /bin/bash
Установим права на конфигурационный файл
$ sudo chmod 600 /etc/sssd/sssd.conf
Система ещё не в домене, поэтому работа службы sssd невозможна, отключим и остановим её, а так же выполним очистку кэша:
$ sudo systemctl disable sssd
$ sudo systemctl stop sssd
$ (sudo rm -f /var/lib/sss/db/* ) && (sudo rm -f /var/lib/sss/mc/* )
Отключаем и останавливаем nmbd:
$ sudo systemctl disable nmbd
$ sudo systemctl stop nmbd
Выполняем настройку Samba:
$ sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.orig
$ sudo nano /etc/samba/smb.conf
[global]
# Basic Samba configuration
#
workgroup = HOLDING
realm = HOLDING.COM
netbios name = TM-Server
security = ads
kerberos method = secrets and keytab
client signing = yes
client use spnego = yes
server min protocol = SMB3_02
idmap config *:backend = tdb
idmap config *:range = 3000-7999
idmap config HOLDING.COM:backend = rid
idmap config HOLDING.COM:range = 10000-999999
# Turn off printing to avoid log spam
#
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
# Special configuration for Apple's Time Machine
#
fruit:model = MacPro
fruit:advertise_fullsync = true
fruit:aapl = yes
# Logging
#
log file = /var/log/samba/%m.log
#log level = 10
max log size = 1000
[TimeMachine]
root preexec = /etc/samba/mkhomedir.sh %U
path = /mnt/timemachine/%U
fruit:time machine = yes
spotlight = yes
valid users = @TimeMachine-Users@holding.com
read only = no
vfs objects = catia fruit streams_xattr
ea support = yes
inherit permissions = yes
Проверяем корректность настроек
$ testparm
Система выдаст предупреждение о лимите открытых файлов который в Linux и Windows отличается
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Исправляем:
$ ulimit -n 16384
Для того, чтобы изменения применялись после каждой загрузки сервера, необходимо отредактировать конфигурацию системы, добавив строки:
$ sudo nano /etc/security/limits.conf
* - nofile 16384
root - nofile 16384
Выполним настройку автоматического создания каталога пользователя:
$ sudo nano /etc/samba/mkhomedir.sh
#!/bin/bash
if [ ! -e /mnt/timemachine/$1 ]; then
mkdir -m 700 /mnt/timemachine/$1
chown $1 /mnt/timemachine/$1
fi
exit 0
Разрешим выполнение скрипта:
$ sudo chmod +x /etc/samba/mkhomedir.sh
Попробуем получить билет Kerberos пользователя, учётные данные которого будут использоваться для ввода сервера в домен:
$ sudo kinit AdminUser
Проверим билет Kerberos:
$ sudo klist
Присоединим сервер к домену, используя ранее полученный билет Kerberos :
$ sudo net ads join -k osName='Debian GNU/Linux' osVer='10.0 (Buster)'
Получим и проверим билет Kerberos для учётной записи сервера:
$ sudo kinit -k TM-Server$
$ sudo klist
Если ввод в домен осуществлялся не с правами учётной записи администратора домена, то для учётной записи сервера необходимо отдельно зарегистрировать запись SPN, которая требуется для работы протокола Kerberos. Сделать это можно на любой Windows-системе, присоединённой к домену следующей командой:
setspn -A HOST/TM-Server.holding.com TM-Server
Включаем и запускаем SSSD:
$ sudo systemctl enable sssd
$ sudo systemctl start sssd
Теперь настроим Linux для работы с доменными пользователями, чтобы в дальнейшем использовать свои административные учётные записи Active Directory для администрирования сервера.
Автоматическое создание домашнего каталога для доменных пользователей:
$ sudo nano /etc/pam.d/common-session
session required pam_mkhomedir.so umask=0022 skel=/etc/skel
Настройка PAM для ограниченного входа в систему группам пользователей:
$ sudo nano /etc/access-groups-to-system
sudo
root
Linux-Admins@holding.com
Установим права на файл:
$ sudo chown root:root /etc/access-groups-to-system
$ sudo chmod 600 /etc/access-groups-to-system
Опишем в PAM использование нашего файла с перечнем разрешённых логинов/групп:
$ sudo nano /etc/pam.d/login
...
# Restricted access to service from local and domain groups
account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/access-groups-to-system
...
Настройка sudo для группы доменных пользователей:
$ sudo nano /etc/sudoers.d/linux-admins
%Linux-Admins@holding.com ALL=(ALL) ALL
$ sudo chmod 0440 /etc/sudoers.d/linux-admins
Настройка PAM для SSH-подключений:
$ sudo nano /etc/pam.d/sshd
...
# Restricted access to service from local and domain groups
account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/access-groups-to-system
...
Настроим конфигурацию SSH-сервера:
$ sudo nano /etc/ssh/sshd_config
Изменим следующие строки:
Port 22
ListenAddress 10.28.35.20
# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
Перезапустим службу SSH-сервера:
$ sudo systemctl restart sshd
Напоследок подключим диск, на котором будут хранится резервные копии.
Посмотрим, какой диск виртуальной машины доступен
$ sudo fdisk --list
В нашем примере будет использоваться диск /dev/sdb. Выполним на этом диске разметку:
$ sudo fdisk /dev/sdb
n — создаём новый раздел
p — проверяем результат
w — записываем изменения
Форматируем созданный раздел в файловую систему ext4:
$ sudo mkfs.ext4 /dev/sdb1
Создаём точку монтирования:
$ sudo mkdir /mnt/timemachine
Узнаём необходимый для монтированная идентификатор UUID диска:
$ sudo blkid /dev/sdb1
Настраиваем авто-монтирование диска при каждой загрузке сервера:
$ sudo nano /etc/fstab
...
# Time Machine disk
#
UUID=7d7932b8-ea6f-4507-99b4-613322765d21 /mnt/timemachine ext4 defaults 0 0
Применяем изменения в fstab
$ sudo mount -a
Установим доменную группу на каталог резервных копий:
$ sudo chgrp "TimeMachine-Users@holding.com" /mnt/timemachine
Перезапустим службу Samba:
$ sudo systemctl restart smbd
Организация сетевого ресурса для Time Machine на Windows Server
По умолчанию, Time Machine не поддерживает SMB ресурсы организованные на Windows Server, так как Windows Server не имеет расширения F_FULLSYNC. Поэтому мы вручную создадим, так называемый (в терминологии локализованной версии macOS), "рассеянный" (sparsebundle) пакетный образ диска и разместим его на этом сетевом ресурсе.
Подключим сетевой ресурс и создадим на нём рассеянный пакетный образ диска с помощью Disk Utility.app
- Имя файла: имя хоста
- Имя раздела: Резервные копии Time Machine
- Размер устанавливаем в зависимости от потребностей
- Файловая система: Mac OS Extended (Чувствительный к регистру символов, журналируемый)
- Шифрование: устанавливаем если мы хотим иметь зашифрованную резервную копию
- Раздел: Одиночный раздел — Схема разделов GUID
- Формат: Рассеянный пакетный образ диска
Создать образ sparsebundle можно и с помощью Terminal.app:
hdiutil create -encryption AES-256 -size 150g -type SPARSEBUNDLE -imagekey sparse-band-size=1024000 -fs "Case-sensitive Journaled HFS+" -volname "Резервные копии TimeMachine" /Volumes/backups-macos\$/$(hostname -s).sparsebundle
Отдельное внимание можно уделить ключу "-imagekey sparse-band-size=", который по умолчанию имеет значение 16384. С помощью него можно регулировать размер части диска, с учётом 512 байт на сектор. То есть по умолчанию размер части равен 8 Мб, а в примере 512 Мб.
После создания образа дисковой утилитой, он автоматически подключится в систему. Теперь необходимо включить на этом образе параметр enableOwnership, для того, чтобы Time Machine мог управлять разрешениями.
Откроем Terminal.app и узнаем каким устройством подключен образ:
$ diskutil list
Включим управление владением
$ sudo diskutil enableOwnership /dev/disk3s2
Проверить состояние параметра можно как в терминале, так и в дисковой утилите
$ diskutil info disk3s2 | grep Owner
В Disk Utility.app информация об этом параметре "Владельцы включены" обновится только после переподключения образа. Однако, необходимо иметь ввиду, что данный параметр хранится на той системе, где он был включен и находится в файле /var/db/volinfo.database. Это можно проверить, но сперва узнаем идентификатор тома:
$ diskutil info /dev/disk3s2 | grep "Volume UUID"
Volume UUID: 07550ADF-1BC3-397B-95E9-B3DC77F94C54
Затем прочтём файл
$ sudo cat /var/db/volinfo.database | grep 07550ADF
07550ADF-1BC3-397B-95E9-B3DC77F94C54: 00000001
Для того, чтобы метод работал, необходимо заранее монтировать образ в систему при входе пользователя, создадим приложение на Apple Script:
tell application "Finder"
try
mount volume "smb://File-Cluster.holding.com/backups-macos$"
end try
end tell
try
do shell script "hdiutil attach /Volumes/backups-macos$/$(hostname -s).sparsebundle"
end try
Экспортируем его как "Программа", затем добавляем в автозагрузку при входе пользователя.
Для подобного метода резервного копирования на sparsebundle-диск можно использовать и другие и другие сетевые ресурсы, например NFS.
Подключение сетевого ресурса к Time Machine
При относительно небольшом количестве клиентов подключения можно выполнить вручную, используя утилиту терминала tmutil.
Если подключаемся к сетевому расположению, то пример команды будет выглядеть так:
$ sudo tmutil setdestination smb://$USER:password@TM-Server.holding.com/timemachine
Несмотря на то, что клиентская машина с macOS в домене и у нас имеется сквозная аутентификация, здесь необходимо будет явным образом указать имя пользователя и пароль.
Если подключаемся к смонтированному HOSTNAME.sparsebundle на сетевом ресурсе:
$ sudo tmutil setdestination /Volumes/Резервные\ копии\ Time\ Machine/
Посмотреть информацию о существующих расположениях Time Machine:
$ tmutil destinationinfo
Если в компании много компьютеров на базе macOS, то настраивать каждый из них вручную будет не совсем интересно. В таком случае для массовой настройки можно воспользоваться Profile Manager.
В группе macOS, секции Login Items, настроим аутентификацию пользователя на сетевом ресурсе.
В секции Time Machine укажем путь до сетевого каталога и параметры резервного копирования.
Для вступления параметров в силу необходим релогин. После применения параметров, пользователь сможет управлять только исключениями каталогов из резервного копирования.
Проверка восстановления из резервной копии
После того, как создана хотя бы одна резервная копия, мы можем проверить восстановление файлов.
Перейдём в каталог, в котором хотим выполнить восстановление, вызовем spotlight сочетанием клавиш ⌘+пробел и откроем Time Machine. Остаётся выбрать файлы или каталоги, которые необходимо восстановить.
Подобным образом можно восстанавливать удалённые письма в приложении Mail.app.
Для восстановления операционной системы после критических сбоев, замены HDD/SSD или переноса конфигурации на новый Mac, необходимо воспользоваться macOS Recovery. После загрузки macOS Recovery переходим в Time Machine, выполняем подключение к "Другой сервер", прописываем сетевой путь до каталога с резервными копиями:
При необходимости, система запросит учетные данные для подключения к сетевому ресурсу и ключ для зашифрованной резервной копии.
RSS - Записи
Добавить комментарий