Синхронізувати час у мережі ntp debian. Базове налаштування сервера Debian після інсталяції. Встановлення та налаштування screen

Я використовую операційну систему Debian GNU/Linux на серверах для хостингу сайтів. Коли влітку 2017 вийшла версія 9 Stretch, я зрадів тому, що для неї в репозиторіях «з коробки» був доступний PHP 7. Який, як відомо, працює швидше за PHP 5.

У цій статті я покажу, що з налаштуванням часу на Debian 9 так само стало краще, не потрібно нічого качати і встановлювати додатково, зокрема демон ntp або утиліту ntpdate. Все відмінно налаштовується та працює на стандартному наборі програмного забезпечення Debian 9 завдяки оновленій версії systemd, в якому є окрема служба, що відповідає за синхронізацію часу системи за протоколом NTP.

Як настроїти час Debian 9

Для початку потрібно визначитися зі своїм часовим поясом та встановити його, у мене це виглядає так:

# timedatectl set-timezone Europe/Volgograd

Потім потрібно відредагувати файл /etc/systemd/timesyncd.conf, вказавши в ньому сервери для синхронізації часу, наприклад:

# Цей файл є частиною системи. # # systemd is free software; Ви можете відремонтувати його і/або змінити його під терміни GNU Lesser General Public License. either version 2.1 of License, або # (at your option) any later version. # # Entries in this file show the compile time defaults. # Ви можете змінити налаштування за допомогою цього файлу. # Defaults can be restored by simply deleting this file. # # See timesyncd.conf(5) for details. NTP=ru.pool.ntp.org FallbackNTP=pool.ntp.org

Тут в опції NTP=вказуються пріоритетні сервери для синхронізації часу. Якщо при зверненні до них відбудеться збій, то використовуватимуться сервери, зазначені в FallbackNTP=.

Після внесення змін до файлу конфігурації необхідно перезапустити сервіс синхронізації часу:

# systemctl restart systemd-timesyncd

Стан налаштування часу можна перевірити наступною командою:

# timedatectl status

Результат нижче говорить про те, що годинник на моєму сервері налаштований правильно і синхронізується за протоколом NTP.

Local time: Tue 2018-12-18 16:36:33 +04 Universal time: Tue 2018-12-18 12:36:33 UTC RTC time: Tue 2018-12-18 12:36:33 Time zone: Europe/ Volgograd (+04, +0400) Network time on: yes NTP synchronized: yes RTC in local TZ: no

тут,
Local time- це місцевий час;
Universal time- час UTC (світовий координований час). Це відправна точка для відліку всіх часових поясів;
RTC time- час в апаратному годиннику сервера (комп'ютера);
Time Zone- Ваш часовий пояс;
Network time on- вказує, чи включений ntp-клієнт, що входить до складу systemd;
NTP synchronized- повідомляє, чи синхронізовано час із ntp-сервером;
RTC in local TZ- показує, який час зберігається в апаратному годиннику: локальне або всесвітнє. При цьому, yesозначає локальний час, no- всесвітнє;

Інформація для новачків

Мене іноді запитують, де вводити (виконувати) команди, що наводяться мною?

Усі наведені у цій статті команди потрібно виконувати у консолі сервера від імені привілейованого користувача (root). Знак # (октоторп, грати, діез, хеш) якраз говорить про це.

Як консольний клієнт для віддаленого підключення до серверів я використовую програму

На сервері важливо підтримувати більш-менш точний час. Щоб було зручно читати логи, щоб ваш сервер не надсилав іншим листи з минулого чи з майбутнього, щоб… та пофіг — просто важливо і все.
Через різні глюки, помилки в залізі, вимикання-вмикання, час на сервері може відставати-спішати щодо атомного часу. Зазвичай – не більше ніж на секунду за добу, на практиці – на секунду за місяць, а то й менше. Але хрінова працююче залізо може базікати час набагато сильніше (загалом сильні коливання часу — привід задуматися про здоров'я залізця).
Існує два популярні способи синхронізації часу в linux - ntpdate по кроні, або постійно запущений ntpd. Ви вільні вибрати будь-який з них, я напишу про обох. Але від себе я все ж таки раджу використовувати саме ntpdate по крону, особливо якщо вам не сильно критично постійно тримати на сервері час з похибкою менше 0.1с.
C ntpd була пов'язана проблема, коли вразливість у ньому дозволяла використовувати сервери ntpd для проведення udp amplification-атаки (коли маленький пакет, пущений у бік вашого сервера дозволяв згенерувати великий udp-пакет у бік чужого сервера) - http://habrahabr.ru /post/209438/
Звичайно, ту вразливість пофіксували (та й написали, як від неї врятуватися без оновлень ntpd), але де гарантії, що там не залишилося подібних проблем? Та й, знову ж таки, ntpd все ще працює по udp і атаки схожого типу можливі, хоч і без великого посилення трафіку (зате це дозволить приховати атакуючого, підставивши ваш сервер під абузу). До речі, я стикався з тим, що ntpd, вбудований в ipmi-модуль сервера був схильний до цієї атаки і весело ддосил сусідів по країні =)
Тому, якщо ви не готові постійно читати розсилки безпеки, стежити за оновленнями і так далі - все ж таки не варто ставити ntpd.
Отже, перший спосіб: запускаємо ntpdate раз на добу по крону.
Зносимо ntpd, якщо він є:

[email protected]:~# apt-get remove --purge ntpd

Ставимо ntpdate:

[email protected]:~# apt-get install ntpdate

І створюємо файл /etc/cron.d/ntpdate з таким вмістом:

0 6 * * * root ntpdate ntp.ubuntu.com 1>/dev/null 2>&1

Тепер щодня о 6 ранку (час і періодичність самі підставте) годинник буде підводитись до актуального стану.

Другий спосіб: nptd.
Нам треба навпаки його поставити:

[email protected]:~# apt-get install ntpd

І написати в конфіг /etc/ntpd.confбільш-менш правильну конфігурацію:

disable auth
disable stats
server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org

Після чого перезапускаємо його:

[email protected]:~# /etc/init.d/ntp restart

Все, тепер наші годинники підводяться в режимі реального часу синхронізуються з пулом ntp-серверів.

Точний час на комп'ютері служить не тільки для звіряння людиною дати і часу, але також виконує багато інших важливих завдань. Наприклад, спробуйте перевести свій час на кілька годин тому або повернутися в минуле, вказавши в налаштуваннях 19хх рік. Тепер зайдіть із такою датою на google.com. Швидше за все ви зазнаєте повного фіаско.

У корпоративному середовищі неправильно налаштований час може викликати багато інших помилок: від неможливості автентифікації користувача в системі до... не будемо про сумне.

Є кілька способів налаштування дати та часу. Пам'ятайте, що цей процес торкається системних налаштувань і тому вимагає привілеїв root користувача.

Спосіб №1

Уявляє собою найпростіший спосіб. Найкращий для новачків. Налаштування здійснюється через майстер у псевдографічному режимі.

Dpkg-reconfigure tzdata

Спосіб №2

Майже ідентичний методу №1. Простий і зручний, але цього разу лише у текстовому режимі. Все що від вас потрібно слідувати підказкам майстра

Спосіб №3

Одна з утиліт systemd

Timedadectl set-timezone<название зоны>

Перегляд доступних зон

Timedatectl list-timezones

Спосіб №4

За допомогою утиліти ntpdate. За замовчуванням цю утиліту не встановлено.

Apt install ntp ntpdate

Додайте ntp-сервер у конфігураційний файл /etc/ntp.conf шукайте рядки, що починаються з pool. Детальніше про синтаксис цього файлу man ntp.conf

Зупинимо службу мережного часу для оновлення

Service ntp stop

Отримуємо дані з ntp-сервера

Ntpdate -s<адрес ntp-сервера>

Запускаємо службу назад

Service ntp start

Спосіб №5

Ручне налаштування. Пишемо у файл /etc/timezone потрібну тимчасову зону, наприклад Europe/Moscow

Echo Europe/Moscow > /etc/timezone

Перезаписуємо дані про тимчасову зону.

Ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Отримуємо дані з ntp-сервера

Під час початкової установки Debianми конфігуруємо часовий пояс за допомогою пакета. Надалі синхронізацію часу та часового поясу можна виконати командами:

$ su $ пароль $ dpkg-reconfigure tzdata

Стрілками вибираємо Європата натискаємо Enter .

Також вибираємо часовий пояс.

В результаті синхронізація отримуємо універсальне ( час за Грінвічем) та місцевий час.

Конфігураційний файл зберігається в /etc/timezone . Відкрити файл можна за допомогою команди:

$ gedit /etc/timezone

Крім того, відповідний файл даних знаходиться у каталозі /usr/share/zoneinfo і копіюється в /etc/localtime Цей файл містить правила, що регулюють дату літнього або зимового часу для країн, що його використовують.

У комп'ютері два джерела часу: на материнській платі апаратний годинник - CMOS" і в ядрі операційної системи, контрольовані серверами часу через мережу. На практиці існує проблема, оскільки годинник CMOSє не більше ніж лічильником і не містять жодної інформації про часовий пояс.

Проблема виникає коли комп'ютер у мережі чи має кілька систем (наприклад, запуск інших систем через віртуальну машину) тоді виникає хаос і неясно, який час є правильним.

Синхронізація часу може здатися зайвою на одиночному комп'ютері, але дуже важливою в мережі. Бо у разі нападу легше відновити хронологію подій на різних машинах. Дані зібрані на кількох машинах не матимуть великого сенсу, якщо вони не синхронізовані.

Оскільки комп'ютери регулярно запускаються та перезавантажуються (для економії електроенергії), машини зручно синхронізувати за допомогою NTPпід час завантаження. Для цього просто встановіть ntpdate пакет, що дозволяє швидко синхронізувати годинник комп'ютера з серверами точного часу, під'єднаними до Всесвітньої Павутини. Встановлення ntpdate з репозиторію зробимо за допомогою менеджера пакетів Synaptic або шляхом виконання команд у терміналі:

$ su $ пароль $ apt-get install ntpdate

Для робочих станцій ви можете змінити сервер NTP, що використовується за необхідності шляхом модифікації /etc/default/ntpdate файлу.

Для серверів, оскільки вони рідко перезавантажуються, а є велика необхідність підтримувати точний час, необхідно встановити локальний сервер NTP.

Встановлення NTP

У конфігурації за промовчанням сервер синхронізуватиме з ресурсом pool.ntp.org і забезпечить час у відповідь на запити, що надходять з локальної мережі. Ви можете налаштувати його шляхом редагування /etc/ntp.conf файлу.

З метою безпеки, для доступу до Вашого серверу ззовні, потрібно додати файл /etc/ntp.conf наступні рядки (дані рядки вже можуть бути присутніми):

Disable monitor restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6::1

disable monitor - відключення запитів monlist, які повертають список із останніх 600 клієнтів ntp. restrict default kod nomodify notrap nopeer noquery

restrict -6 default kod nomodify notrap nopeer noquery - Вимкнення запитів статусу сервера.

Також ви можете вказати свої сервери для синхронізації часу, наприклад, адреси NTP серверів Росії: https://www.ntp-servers.net/servers.html і відредагуйте файл /etc/ntp.conf, виконавши команду:

$ gedit /etc/ntp.conf

Разова синхронізація часу

Як приклад використовується сервер ntp1.stratum1.ru:

$ntpdate ntp1.stratum1.ru

До синхронізації

Після синхронізації

Для того щоб організувати постійну синхронізацію часу зробимо установку демона (сервера) ntp

Відредагуйте файл /etc/ntp.conf або створіть його, якщо файлу немає.

$server ntp1.stratum1.ru iburst

Запускаємо ntp і додаємо його автозавантаження

$ /etc/init.d/ntp start $update-rc.d ntp defaults

Після встановлення нового сервера доводиться виконувати той самий набір стандартних налаштувань. Сьогодні ми займемося базовим налаштуванням сервера під керуванням операційної системи Debian. Я наведу практичні поради щодо невеликого підвищення безпеки та зручності адміністрування, засновані на моєму особистому досвіді.

Ця стаття є частиною єдиного циклу статтею про сервер.

Вступ

Будь-яка робота із сервером після найчастіше починається зі стандартних обов'язкових дій, без яких або не вийде просунутися далі, або буде незручно працювати. Наприклад, вам у будь-якому випадку необхідно виконати мережні налаштування, бажано оновити систему та встановити часовий пояс. Рекомендується одразу налаштувати автооновлення часу, підрихтувати параметри sshd, встановити midnight commander та виконати інші налаштування.

Про це я хочу розповісти у статті. Я ділитися своїм реальним досвідом роботи. Це не означає, що треба робити так, як я. Я можу чимось помилятися, щось робити не так зручно, як можна було б зробити. Це просто поради, які комусь допоможуть дізнатися про щось нове, а хтось можливо поділиться зі мною чимось новим для мене, або вкаже на мої помилки. Мені хотілося б, щоб це було так. Своїми матеріалами я не тільки поділяюся з вами знаннями, а й сам дізнаюся про щось нове в тому числі і з коментарів та листів на пошту.

Вказуємо мережеві параметри

Отже, у нас є щойно встановлена ​​система. Дізнатися чи перевірити її версію можна командами:

# uname -a Linux debian10 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux # lsb_release -a No LSB modules available. Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster

Переглянути список пакетів, готових до оновлення, можна за допомогою команди:

# apt list --upgradable

Тепер виконаємо просте оновлення всіх пакетів системи:

Ключ upgradeвиконує лише оновлення однієї версії пакета на іншу, свіжішу. Він не встановлюватиме або видалятиме пакети, навіть якщо це необхідно для оновлення інших. Це найбільш безпечний та надійний варіант оновлення, але він може оновити не все. Наприклад, з її допомогою не оновити ядро ​​до свіжішої версії.

Ключ dist-upgradeабо full-upgrade(це те саме) на додаток до upgrade обробляє всі зміни залежностей для нових пакетів і під час роботи може видаляти непотрібні та ставити необхідні пакети для оновлення. Ось витяг із документації з приводу цих двох ключів.

Тому після звичайного оновлення, робимо ще full-upgrade.

# apt full-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages були автоматично налагоджені і не потрібні: dh-python guile-2.0-libs libbind9- 140 libdns162 ​​libicu57 libisc160 libisccc140 libisccfg140 liblvm2app2.2 liblvm2cmd2.02 liblwres141 libperl5.24 libpython3.5-minimal libpython3.5-stdpyt3 minimal rename sgml-base tcpd xml-core use "apt autoremove" to remove them. 0 upgraded, 0 uploaded, 0 to remove and 0 not upgraded.

Мені пропонується видалити старі пакети, які вже не потрібні. Це залежно від старих версій софту, який вже оновився та отримав нові пакети із залежностей, а ці йому більше не потрібні. Очистимо їх командою:

На цьому оновлення системи закінчено. Якщо ви хочете оновити версію релізу, наприклад, читайте окремий матеріал.

Налаштування ssh

Тепер внесемо деякі зміни до налаштувань сервера ssh. Я рекомендую його запускати на нестандартному порту для виключення зайвих спілкувань із ботами, які регулярно сканують інтернет та підбирають паролі користувачів за словниками.

Існує думка, що змінювати порт ssh це наївність, а не захист. Треба просто налаштувати сертифікати, fail2ban або ще якимось чином захистити порт ssh, наприклад, за допомогою обмежень iptables, і т.д. Тим не менш, я все ж таки рекомендую порт змінити на нестандартний. Навіть якщо у вас все захищено від підбору паролів, так як ви використовуєте сертифікати, зайві запити до порту ssh витрачають ресурси сервера, хоч і не дуже великі. Йде встановлення з'єднання, обмін рукостисканнями тощо. Навіщо вам це потрібно?

За промовчанням у Debian, втім як і в будь-якому іншому дистрибутиві Linux, ssh сервер працює на 22 портах. Змінимо цей порт, наприклад, на 23331. Також я ще змінюю конфігурацію для дозволу підключення по ssh користувача root з використанням пароля. У Debian з коробки користувач root за ssh паролем авторизуватися не може. Змінимо і це. Відкриваємо файл налаштувань:

# nano /etc/ssh/sshd_config

І змінюємо там наступні рядки. Наводимо їх до вигляду:

Port 23331 PermitRootLogin yes

Зберігаємо зміни та перезапускаємо сервер ssh наступною командою:

# service sshd restart

Перевіряємо зміни:

# netstat-tulnp | grep ssh tcp 0 0 0.0.0.0:23331 0.0.0.0:* LISTEN 925/sshd tcp6 0 0:::23331:::* LISTEN 925/sshd

Все гаразд, сервер слухає 23 331 порт. Тепер нове підключення буде здійснено тільки портом 23331. При цьому, після перезапуску ssh, старе підключення не буде розірвано.

Я знаю, що багато хто заперечує проти підключення рутом до сервера. Нібито це небезпечно тощо. і т.п. Мені ці аргументи здаються не переконливими. Не розумію, в чому може бути проблема, якщо я маю нормальний складний пароль на root, який не вийде підібрати або збрутувати. Жодного разу за всю мою роботу системним адміністратором у мене не виникло проблем із цим моментом. А ось працювати так значно зручніше, особливо коли необхідно оперативно кудись підключитися по форс мажорним обставинам.

Окремо тему підключення до сервера під root я розглянув у статті про . Кому цікаво, переходьте в неї і ділитесь своєю думкою з цього приводу.

Установка утиліт mc, htop, iftop

Наступним кроком я налаштовую деякі корисні утиліти, якими регулярно користуюсь у повсякденній роботі. Перша з них – це всім відомий двопанельний файловий менеджер Midnight Commander. Встановимо mcна наш сервер:

# apt install mc

І відразу ж для нього вмикаю підсвічування синтаксису всіх файлів, які не позначені явно у файлі /usr/share/mc/syntax/Syntaxсинтаксисом для sh та bash скриптів. Цей універсальний синтаксис нормально підходить для конфігураційних файлів, із якими найчастіше доводиться працювати на сервері. Перезаписуємо файл unknown.syntax. Саме цей шаблон буде застосовуватися до файлів .conf і .cf, оскільки до них явно не прив'язано жодного синтаксису.

# cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntax

Я відразу ж ставлю редактором за замовчуванням mcedit. Для цього просто вибираю його з меню при першому редагуванні якогось файлу. Якщо у вас таке меню не з'являється, можете викликати його самі та вибрати необхідний редактор за замовчуванням:

# select-editor Select an editor. Для зміни останнього, використовується "select-editor". 1. /bin/nano<---- easiest 2. /usr/bin/mcedit 3. /usr/bin/vim.tiny Choose 1-3 : 2

# apt install htop

Корисною утилітою, що дозволяє дивитися мережеве завантаження в режимі реального часу, є iftop. Дуже рекомендую. Простішого та зручнішого інструменту мені не траплялося, хоча я багато перепробував подібних речей. Встановлюємо iftop на сервер:

# apt install iftop

Налаштування та оновлення часу в Debian

Тепер перевіримо встановлений часовий пояс, час та увімкнемо автоматичну синхронізацію часу з віддаленого сервера. Дуже докладно це питання я розглянув у окремій статті.

Дізнатися дату, час, часовий пояс можна командою date:

Якщо все зазначено правильно, то міняти нічого не потрібно. Якщо ж у вас неправильний час або вказаний часовий пояс, що не відповідає вашому, то налаштувати це можна наступним чином. Спочатку оновимо часові пояси:

# apt install tzdata

Тепер виберемо правильний часовий пояс за допомогою команди:

# dpkg-reconfigure tzdata

Вибираючи відповідні пункти візарду, вказуєте свій часовий пояс.

# apt install ntpdate

І синхронізуємо час:

# ntpdate-debian 12 Aug 14:30:21 ntpdate: adjust time server 89.109.251.21 offset 0.004529 sec

Якщо отримуєте помилку:

Значить, у вас вже працює служба ntp. Її потрібно зупинити та оновити час вручну. Хоча якщо вона працює, то у вас і так має бути все гаразд.

Для того, щоб час автоматично синхронізувався без вашої участі з певною періодичністю, використовується інструмент ntp. Встановимо його:

# apt install ntp

Після встановлення він сам запуститься і автоматично синхронізуватиме годинник сервера. Перевіримо, чи запустився сервіс ntpd:

# netstat-tulnp | grep ntp udp 0 0 10.20.1.16:123 0.0.0.0:* 8855/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 8855/ntpd udp 0 0 0.0.0.0. udp6 0 0 fe80::cce1:23ff:fe4:123:::* 8855/ntpd udp6 0 0::1:123:::* 8855/ntpd udp6 0 0:::123:::* 8855/ntpd

Налаштування firewall (iptables) у Debian

Як firewall у Debian за замовчуванням використовується iptables, його і налаштовуватимемо. Спочатку фаєрвол повністю відкритий та пропускає весь трафік. Перевірити список правил iptables можна наступною командою:

# iptables -L -v -n Chain INPUT (policy ACCEPT 0 пакетів, 0 bytes) pkts bytes target prot opt ​​in source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt ​​in out source destination Chain OUT (policy ACCEPT 0 пакетів, 0 bytes) pkts bytes target prot opt ​​in out source destination

Звертаю увагу на те, що налаштовувати firewall без прямого доступу до консолі сервера не слід. Особливо, якщо ви не дуже знаєте на цьому і копіюєте команди з сайту. Шанс помилитись дуже високий. Ви просто втратите віддалений доступ до сервера.

Створимо файл із правилами iptables:

# mcedit /etc/iptables.sh

Перевіряємо, що правила записалися у файл /etc/iptables_rules. Якщо їх там немає, записуємо їх вручну.

# /sbin/iptables-save > /etc/iptables_rules

Правила застосовувалися і відбувся їх запис у файл /etc/iptables_rules. Тепер потрібно зробити так, щоб вони застосовувалися під час завантаження сервера. Для цього робимо таке. Відкриваємо файл /etc/network/interfacesі додаємо до нього рядок pre-up iptables-restore< /etc/iptables_rules Должно получиться вот так:

# cat /etc/network/interfaces allow-hotplug eth0 iface eth0 inet dhcp pre-up iptables-restore< /etc/iptables_rules

Для перевірки перезавантажте сервер та перегляньте правила iptables. Повинен завантажитися налаштований набір правил із файлу /etc/iptables_rules.

Налаштування логів cron

За промовчанням у Debian немає окремого лог файлу для подій cron, вони всі сипляться в загальний лог /var/log/syslog. Особисто мені це не дуже подобається, я вважаю за краще виводити ці події в окремий файл. Про це я написав окремо. Рекомендую пройти за посиланням та налаштувати, якщо вам це потрібно. Там дуже коротко і тільки у справі, не копіюватиму сюди цю інформацію.

Встановлення та налаштування screen

Я звик у своїй роботі користуватися консольною утилітою screen. Спочатку вона замислювалася як інструмент, який дозволяє запустити щось віддалено в консолі, відключитися від сервера і при цьому все, що виконується в консолі, продовжить свою роботу. Ви зможете спокійно повернутися в ту ж сесію та продовжити роботу.

Спочатку я саме так і використовував цю утиліту. Рідко її запускав, якщо не забував, коли виконувався якийсь тривалий процес, який шкода було перервати через випадкове обрив зв'язку або необхідність відключити ноутбук від мережі і кудись переміститися.

Пізніше я вирішив докладніше ознайомитися з цим інструментом і виявив, що є кілька зручних моментів, які можна використовувати в щоденній роботі. Ось як я використовую утиліту screen. При підключенні до сервера у мене запускається screen з трьома вікнами 1, 2, 3. Перше вікно автоматично переходить у каталог /, друге /etc, третє /var/log. Я осмислено назвав ці вікна: Main, etc, logs відповідно. Внизу знаходиться рядок стану, в якому відображено список всіх відкритих вікон і активне вікно.

За допомогою гарячих клавіш я дуже швидко перемикаюся між вікнами у разі потреби. Ось як виглядає моє робоче вікно ssh підключення:

Перемикаюся між вікнами за допомогою стандартних гарячих клавіш screen: ctrl+a 1, ctrl+a 2, ctrl+a 3. Я спеціально змінив нумерацію, щоб вона починалася не з 0 по дефолту, а з 1. Так зручніше на клавіатурі перемикати вікна . Кнопка 0 знаходиться надто далеко від 1 та 2.

Щоб налаштувати таку ж роботу screen, як у мене, достатньо виконати декілька простих дій. Спочатку встановлюємо screen:

# apt install screen

Створюємо в каталозі /rootконфігураційний файл .screenrcнаступного змісту:

# mcedit /root/.screenrc #Виводимо рядок стану hardstatus alwayslastline "%-Lw%(= BW)%50>%n%f* %t%(-)%+Lw%<" # Добавляем некоторые настройки startup_message off defscrollback 1000 defutf8 on shell -$SHELL # Создаем несколько окон chdir screen -t Main 1 chdir /etc screen -t etc 2 chdir /var/log screen -t logs 3 # Активное первое окно после запуска select 1

Для знайомства з налаштуваннями, гарячими клавішами та варіантами застосування утиліти screen можна за адресою http://itman.in/ssh-screen/ Мені допоміг цей матеріал. Написано коротко, у справі та зрозуміло.

Висновок

Тепер можна перезавантажити сервер і перевірити, чи все гаразд. У мене все гаразд, перевірив:) На цьому базове налаштування сервера debian закінчено. Можна приступати до конфігурації різних сервісів, під які він налаштовувався. Про це я розповідаю в окремих статтях.

Нагадую, що ця стаття є частиною єдиного циклу статтею про сервер .

Онлайн курс "Мережевий інженер"

• Курс містить дві проектні роботи.;
• Студенти зараховуються до офіційної академії Cisco (OTUS, Cisco Academy, ID 400051208) та отримують доступ до всіх частин курсу «CCNA Routing and Switching»;
• Студенти можуть скласти іспит та отримати разом із сертифікатом OTUS ще сертифікат курсу «CCNA Routing and Switching: Scaling Networks»;