Наверх

База знаний
Try 2 Fix
beta

Ubuntu: смена часового пояса и синхронизация времени

Ubuntu: смена часового пояса и синхронизация времени

Любой сервер нуждается в выставлении точного времени. Это нужно для самых различных вещей, начиная от сбора корректных логов, заканчивая работой WEB-приложений, в работе которых участвуют сертификаты. Установка точного времени складывается из двух частей: синхронизация самого времени и установка правильного часового пояса. Посмотрим, как нам это сделать.

Признание проблемы — это половина её решения. Давайте проверим, что на нашем тестовом сервере со временем:

date

Увидим примерно такой вывод:

Ср. окт. 31 02:05:13 -01 2018

День недели и месяц (на момент написания статьи) совпадают с реальным, а вот время и часовой пояс (-1) явно не наши.
Займёмся сначала установкой часового пояса. Для этого от имени суперпользователя выполним команду:

sudo dpkg-reconfigure tzdata

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

Current default time zone: 'Europe/Moscow'
Local time is now: Wed Oct 31 06:07:22 MSK 2018.
Universal Time is now: Wed Oct 31 03:07:22 UTC 2018.

Всё отлично, наш часовой пояс изменился. Осталось только синхронизировать время. Для этого воспользуемся командой

sudo ntpdate 0.pool.ntp.org

Если пакет ntpdate не установлен, то его можно установить одной командой:

sudo apt-get install ntpdate

Ещё раз проверим время командой date.  Готово! Время нашего сервера синхронизировано!

Эти статьи будут Вам интересны

Анализ MEMORY.DMP после возникновения «Синего экрана смерти» (BSOD)

Синий экран для владельцев ПК с ОС Windows скорее норма, нежели что-то из ряда вон выходящее. Однако сам код ошибки, который мы можем увидеть на экране иногда бывает неинформативен, а ещё чаще ПК перезагружается раньше, чем мы можем его запомнить. На этот случай у нас есть файл MEMORY.DMP, который хранит всю информацию о падении системы. Показываем, как его проанализировать.

Тюнинг PostgreSQL 9.4.2-1.1C для 1С:Предприятия 8.3: рельаный опыт настройки

Как только размер файловой базы данных 1С:Предприятие одного из наших клиентов достиг размера в 32Гб (да, 32Гб), в следствии чего всё постепенно начало тормозить, а потом и встало намертво, наши клиенты попросили нас решить эту проблемы. SSD Enterprise класса ненадолго подсластил пилюлю, но через некоторое время всё вернулось в исходную точку. Ну что ж, тут и к бабке не ходи – переходим на SQL версию БД. Поскольку мы ярые пользователи Windows, доступно нам только два варианта СУБД – это MSSql и PostgreSQL. Первый хорош до безумия, но стоимость не порадовала. А ещё больше не порадовала новость о дополнительных лицензиях 1С для работы с MSSQL. Поэтому PostgreSQL. Подробная инструкция с видео доступна здесь. В этой статье мы пройдёмся по ключевым моментам. Не забываем про резервное копирование баз данных 1С! Исходные данные: ОС Windows Server 2008R2, Intel Core i7-2600K 3.40GHz, 32Gb RAM, Intel SSD DC3700 100Gb (только под БД, ОС на отдельном SSD), от 10 до 20 пользователей в БД ежедневно, обмен с 5 узлами распределённой БД в фоне. Зловеще, не правда ли? Приступим.

Honeywell Metrologic MS3780 не считывает штрих-код EAN13 + EAN5

У одного нашего клиента множество похожего товара, но всё-таки разного. Поэтому производитель печатает на товаре не привычный штрих-код EAN13, а EAN13 с дополнительными 5 символами, то есть EAN13 + EAN5. И так случилось, что сканер не считывает эти дополнительные символы. Решаем эту проблему.