Настройка времени в домене Windows Server 2008 R2 и новее

w32tm

 

 

 

 

 

 

 

 

 
Как известно, в Windows Server 2008 R2 стало невозможным настраивать источник времени командой net time, для этого необходимо использовать команду w32tm. Эта команда предназначена для настройки службы Windows Time и имеет широкий набор аргументов, описание которых можно увидеть, запустив ее с ключом /?. В этой статье я опишу несколько типичных вариантов использования команды w32tm.

w32tm /query /source — выводит источник времени, на который настроена служба Windows Time
w32tm /monitor — при запуске на контроллере домена (КД) показывает, насколько отличается время на других КД и на внешнем источнике времени, на который настроен PDC
w32tm /config /syncfromflags:manual /manualpeerlist:ru.pool.ntp.org — настройка в качестве источника времени пула ntp-серверов ru.pool.ntp.org
w32tm /config /update — эту команду необходимо выполнить, чтобы служба времени применила новые настройки
w32tm /resync — выполнение синхронизации времени
w32tm /unregister — отменяет регистрацию службы и удаляет настройки из реестра
w32tm /register — регистрирует службу и восстанавливает настройки по умолчанию

Настройки службы Windows Time хранятся в реестре в ветке
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\

Период синхронизации задается в ветке реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient
ключ SpecialPollInterval содержит интервал синхронизации в секундах

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

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

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

Получение бесплатных ssl сертификатов и установка их в Proxmox

Proxmox https

В данном посте я решаю сразу 2 задачи. Первая, это получение халявного валидного ssl сертификата\ов на который не будут ругаться все современные браузеры (ну или почти все) на всех платформах (ну или почти на всех).

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

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

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

http://habrahabr.ru/post/127643/

2. Подготовка сертификатов

Сертификаты надо перегенерировать в PEM формат и расшифровать закрытый ключ. После манипуляций мы должны получить следующее:

ca.crt : CA сертификат в PEM формате
server.key : не защищенный паролем приватный ключ
server.pem : сертификат сервера в PEM формате

Все это я делю тут https://sslguru.ru/ssl-tools.html и сильно не запариваюсь. У кого паранойя и повышенные требования к безопасности, могут все сделать через командную строку.

3. Установка сертификатов

Делаем бэкап родных сертификатов

cp /etc/pve/pve-root-ca.pem /etc/pve/pve-root-ca.pem.orig
cp /etc/pve/local/pve-ssl.key /etc/pve/local/pve-ssl.key.orig
cp /etc/pve/local/pve-ssl.pem /etc/pve/local/pve-ssl.pem.orig

Копируем свои сертификаты в нужные места

cp server.key /etc/pve/local/pve-ssl.key
cp server.pem /etc/pve/local/pve-ssl.pem
cp ca.pem /etc/pve/pve-root-ca.pem

Перезапускаемся

service pveproxy restart && service pvedaemon restart

Если у вас есть кластер, то сертификаты надо установить на все ноды (только те, что по этому пути /etc/pve/local). А потом внимательно проверить каждую ноду на нормальную работу.

Авто reboot при kernel panic

kernel panic

Я думаю каждый, кто давно имеет дело с Unix образными ОС сталкивался с kernel panic и так же, все знают типичное поведение системе при этом событие — ожидание ручной перезагрузки, или выключения.

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

Уже очень давно в  GNU/Linux, FreeBSD и Solaris, существует возможность изменить стандартное поведение функции panic() и производить перезагрузку компьютера автоматически. В GNU/Linux данная настройка осуществляется при помощи procfs:
echo 5 > /proc/sys/kernel/panic

Чтобы изменения действовали в GNU/Linux и после перезагрузки, необходимо добавить в файл /etc/sysctl.conf строку:
kernel.panic=5

Значение параметра kernel.panic — количество секунд, после которых произойдёт перезагрузка. При установке отрицательного или равного 0 значения этого параметра, автоматической перезагрузки не произойдёт.

Также в системах BSD есть специальная опция в ядре. Цитата из файла /usr/src/sys/conf/NOTES:

# Set the amount of time (in seconds) the system will wait before
# rebooting automatically when a kernel panic occurs. If set to (-1),
# the system will wait indefinitely until a key is pressed on the
# console.
options PANIC_REBOOT_WAIT_TIME=16

В Solaris автоматическая перезагрузка после Kernel panic является стандартным поведением системы. 

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

Встала задача перенести PostgreSQL базу из под самописной CRM со старого физического сервера, на новый виртуальный и как всегда, вылезли проблемы..

Проблема номер раз — простым копированием файлы данных не перенести из за разницы в архитектуре, нет, это можно сделать, но с ОЧЕНЬ большим геморроем.

Проблема номер два — все 200 пользователей которые работают в CRM не записаны внутри базы, а созданы как пользователи PostgreSQL, т.е. простым бэкапом базу перенести конечно можно, но вот пользователей нет. Поэтому единственным разумным решением оказался бэкап через pg_dumpall всего сервера, потом удаление ненужного, расчесывание и полировка.

Ну а раз я взялся за это редкое для меня дело, решил описать подробную процедуру начиная с установки PostgreSQL на Debian 7.5 и заканчивая переносом базы и подключением к ней с другой машины через pgAdmin III.

1. Подготовка чистого сервера, установка необходимого минимума.

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

Начнем установку.

aptitude install postgresql mc ssh screen

screen тут почти обязательная штука, ибо без него очень неудобно, ведь далее придется делать все из под пользователя postgres. После того, как все поставили, нам надо пере инициировать кластер в нужной локале, дабы избежать проблем с кодировкой. Запускаем screen, делаем два окна, в одном из окно меняем пользователя на того, из под которого работает база.

su - postgres

Во втором окне, которое под root останавливаем сервер:

service postgresql stop

идем сюда /var/lib/postgresql/9.1/main и переносим куда нибудь содержимое (обратите внимание, в разных дистрибутивах путь может различаться).

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

/usr/lib/postgresql/9.1/bin/initdb --locale=ru_RU.utf8 /var/lib/postgresql/9.1/main

Далее в другом окне screen не запуская сервер копируем симлинки server.crt и server.key из нашего бэкапа. После этого можно попробовать запустить сервер, ошибок быть не должно.

2. Теперь настраиваем доступ к базе по сети.   Меняем в конфиге postgresql.conf слушаемый интерфейс, я всегда ставлю «*» и не понимаю тех, кто заморачивается указанием ip внутри сети:

nano /var/lib/postgres/data/postgresql.conf
listen_addresses = '*'

А в конфиге pg_hba.conf определяем по какому подключению, кто, к какой базе, с какого адреса и с каким методом авторизации может подключиться. У меня разрешено подключение с любого ipv4 адреса. Подробнее о настройке pg_hba.conf можно почитать тут разжевано все и очень доступно.

nano /var/lib/postgres/data/pg_hba.conf
host all all 0.0.0.0/0 trust

3. Перенос базы. Обычно в мануалах, после настройки доступа устанавливают пароль для системного пользователя postgres, но т.к. я переношу уже настроенный сервер, мне это делать не надо. Осталось просто слить конфигурацию со всеми базами из под системного пользователя на старом сервере:

pg_dumpall > backup

И так же под системным пользователем залить бэкап в новый сервер (назначением для заливки указываем системную базу postgres):

psql -f backup postgres

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

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

P.S. Что бы не забыть, решил сохранить настройку беспарольного входа в psql.

Для автологина создаем на сервере с базой в корне домашней директории пользователя файлик:

touch /root/.pgpass

nano /root/.pgpass

И пишем внутрь:

127.0.0.1:5432:*:postgres:pass

Т.е.  разрешен автологин с локалхоста на стандартный порт postgresql 5432 ко всем базам на сервере для пользователя postgres, и последним указан пароль.

Далее, нужно выставить права на файлик:

chmod 600 /root/.pgpass
chown postgres:postgres /root/.pgpass

И можно наслаждаться конструкциями вида (с ключом -w):

/usr/bin/psql --dbname baza --host 127.0.0.1 --port 5432 --username pip -w --command "vacuum full analyze;"

Настройка ip-ip тоннеля с IPsec шифрованием в Debian

Данная статья написана на основе моих мучений с тоннелем между нашими основными офисами. Исторически сложилось, что тоннель этот, был построен на базе ip-ip + IPsec и изначально он был между двумя FreeBSD шлюзами.

Шло время и шлюзы начали помирать. Вначале, умер один шлюз и нужно было его оперативно заменить, что и было сделано. Вместо него встал шлюза на моем любимом Debian.

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

IPsec был настроен на работу между внешними ip, и тоннель работал между внешними ip, но однажды случился факап (4 провайдера назад), были изменены внешние ip, в конфигах ip-ip тоннеля они были поправлен — в IPsec нет. Вот и вышло, что IPsec не работал.

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

Забил ровно до момента смерти второго BSD шлюза. Вместо умершего шлюза, был так же поставлен Debian и началось шаманство. Дабы учесть ошибки прошлого, и сделать все хорошо, я решил употребить иную схему применения связки ip-ip + IPsec — поднять ip-ip тоннель, а уже его содержимое, обернуть в IPsec.

Зачем я вообще решил оставить ip-ip тоннель?

И действительно, все мануалы, в том числе и официальная wiki решали задачу обходясь без тоннелей, т.е. просто шифровали трафик между внешними ip, для удобства привязывая их к виртуальным сетевушкам, а иногда и без них.

Вот официальная wiki в ней обошлись без сетевух. Тут повторили конфиг из wiki, но с применением виртуальных интерфейсов eth0:1.

Я не стал делать так, про нескольким причинам:

1. При шифрование трафика между внешними ip неминуемого появляется дырка в безопасности, в виде spoofing, т.е. на внешнем интересе, где должны быть сети класса А, появится сеть класса С и их придется разрешить.

2. Трафик между шлюзами, очень тяжело считать. Гораздо проще считать трафик на интерфейсе, чем трафик между сетями. Виртуальный eth0:1 тут тоже не спасает, ибо считается устаревшим и убогим и не поддерживается iptables.

3. Не наглядность конфигурации. Это конечно спорный момент, но для меня это так.

4. Усложнение, точнее нагромождение маршрутизации. Я люблю, когда все маршруты, идут через свои устройства. Это наглядно, это понятно.

Может быть описанные выше причины кому то покажутся и не причинами вовсе. Но у меня так.

При таком подходе я получаю полноценный интерфейс tun0, на котором можно легко и просто считать трафик, на основе которого получаются внятные маршруты, и который полностью поддерживается iptables. Конфигурация IPsec перестает зависеть от внешних ip и от маршрутизируемых сетей, что упрощает перенастройку, в случае чего.

В общем, к делу.

Ставим:  apt-get install racoon ipsec-tools

Вводные данные:

Внутренняя сеть на объекте А — 192.168.16.0/21

IP в тоннеля на стороне А — 192.168.77.1

Внешний IP на объекте А — 10.0.0.65

Внутренняя сеть на объекте В — 192.168.0.0/24

IP в тоннеля на стороне В — 192.168.77.2

Внешний IP на объекте В — 195.0.0.65

И настраиваем на первом шлюзе А в /etc/network/interfaces:

auto tun0
 iface tun0 inet static
 address 192.168.77.1
 network 255.255.255.255
 pointopoint 192.168.77.2
 mtu 1350
 pre-up /sbin/ip tunnel add tun0 mode ipip remote <strong>195.0.0.65</strong> local <strong>10.0.0.65</strong> dev eth0
 pre-up /sbin/ip link set tun0 up
 post-up /sbin/ip route add 192.168.0.0/24 dev tun0 src 192.168.77.1
 pre-down /sbin/ip route del 192.168.0.0/24 dev tun0 src 192.168.77.1
 post-down /sbin/ip link set tun0 down
 post-down /sbin/ip tunnel del tun0

И настраиваем на первом шлюзе В в /etc/network/interfaces:

auto tun0
 iface tun0 inet static
 address 192.168.77.2
 network 255.255.255.255
 pointopoint 192.168.77.1
 mtu 1350
 pre-up /sbin/ip tunnel add tun0 mode ipip remote <strong>10.0.0.65</strong> local <strong>195.0.0.65</strong> dev eth0
 pre-up /sbin/ip link set tun0 up
 post-up /sbin/ip route add 192.168.16.0/21 dev tun0 src 192.168.77.2
 pre-down /sbin/ip route del 192.168.16.0/21 dev tun0 src 192.168.77.2
 post-down /sbin/ip link set tun0 down
 post-down /sbin/ip tunnel del tun0

Так мы создали ip-ip тоннель между объектами и прописали маршруты через тоннель, до внутренних сетей. После перезагрузки или ifup tun0 пинги из сити А в сеть В и обратно должны ходить.

Теперь настраиваем IPsec:

В /etc/racoon/psk.txt  на объекте А пишем придуманную фразу и ip объекта В:

192.168.77.2  tryamromashka888

В /etc/racoon/psk.txt  на объекте В пишем придуманную фразу и ip объекта А:

192.168.77.1  tryamromashka888

В psk.txt на обоих объектах, вместо ip можно поставить звездочку, дабы не заморачиваться.

Конфиг /etc/racoon/racoon.conf на объекте А приводим к такому виду:

path pre_shared_key "/etc/racoon/psk.txt";
remote anonymous {
 exchange_mode main,aggressive;
 proposal {
 encryption_algorithm 3des;
 hash_algorithm sha1;
 authentication_method pre_shared_key;
 dh_group 2;
 }
 }
sainfo address 192.168.16.0/21 any address 192.168.0.0/24 any {
 pfs_group 2;
 lifetime time 1 hour;
 encryption_algorithm 3des, blowfish 448, rijndael;
 authentication_algorithm hmac_sha1, hmac_md5;
 compression_algorithm deflate;
 }

Конфиг /etc/racoon/racoon.conf на объекте В приводим к такому виду:

path pre_shared_key "/etc/racoon/psk.txt";
remote anonymous {
 exchange_mode main,aggressive;
 proposal {
 encryption_algorithm 3des;
 hash_algorithm sha1;
 authentication_method pre_shared_key;
 dh_group 2;
 }
 }
sainfo address 192.168.0.0/24 any address 192.168.16.0/21 any {
 pfs_group 2;
 lifetime time 1 hour;
 encryption_algorithm 3des, blowfish 448, rijndael;
 authentication_algorithm hmac_sha1, hmac_md5;
 compression_algorithm deflate;
 }

Конфиг /etc/ipsec-tools.conf на объекте А приводим к такому виду:

#!/usr/sbin/setkey -f
# NOTE: Do not use this file if you use racoon with racoon-tool
 # utility. racoon-tool will setup SAs and SPDs automatically using
 # /etc/racoon/racoon-tool.conf configuration.
 #
## Flush the SAD and SPD
 #
 flush;
 spdflush;
## Some sample SPDs for use racoon
 
spdadd 192.168.16.0/21 192.168.0.0/24 any -P out ipsec
 esp/tunnel/192.168.77.1-192.168.77.2/require;
spdadd 192.168.0.0/24 192.168.16.0/21 any -P in ipsec
 esp/tunnel/192.168.77.2-192.168.77.1/require;

Конфиг /etc/ipsec-tools.conf на объекте В приводим к такому виду:

#!/usr/sbin/setkey -f
# NOTE: Do not use this file if you use racoon with racoon-tool
 # utility. racoon-tool will setup SAs and SPDs automatically using
 # /etc/racoon/racoon-tool.conf configuration.
 #
## Flush the SAD and SPD
 #
 flush;
 spdflush;
## Some sample SPDs for use racoon
spdadd 192.168.0.0/24 192.168.16.0/21 any -P out ipsec
 esp/tunnel/192.168.77.2-192.168.77.1/require;
spdadd 192.168.16.0/21 192.168.0.0/24 any -P in ipsec
 esp/tunnel/192.168.77.1-192.168.77.2/require;

После этого на обоих шлюзах делаем /etc/init.d/setkey restart && /etc/init.d/racoon restart

и смотрим setkey -D

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

192.168.77.2 192.168.77.1
 esp mode=tunnel spi=248989780(0x0ed74854) reqid=0(0x00000000)
 E: 3des-cbc b976192f e8c17ff6 8fc64e5f 1efda225 c9333c6c 15b03656
 A: hmac-sha1 ae7e03ba d760a471 ef22f01e 0baca744 ef0371c6
 seq=0x00000000 replay=4 flags=0x00000000 state=mature
 created: Sep 9 16:32:56 2015 current: Sep 9 17:02:31 2015
 diff: 1775(s) hard: 3600(s) soft: 2880(s)
 last: Sep 9 16:35:13 2015 hard: 0(s) soft: 0(s)
 current: 260919(bytes) hard: 0(bytes) soft: 0(bytes)
 allocated: 3249 hard: 0 soft: 0
 sadb_seq=1 pid=30197 refcnt=0
 192.168.77.1 192.168.77.2
 esp mode=tunnel spi=52619622(0x0322e966) reqid=0(0x00000000)
 E: 3des-cbc a52242b8 0f0f7042 d92c8011 25242258 34385bc2 4f618b95
 A: hmac-sha1 1e98b340 1db1c65c d7368c5d ffc78cc7 3e9b3a33
 seq=0x00000000 replay=4 flags=0x00000000 state=mature
 created: Sep 9 16:32:56 2015 current: Sep 9 17:02:31 2015
 diff: 1775(s) hard: 3600(s) soft: 2880(s)
 last: Sep 9 16:33:05 2015 hard: 0(s) soft: 0(s)
 current: 2077093(bytes) hard: 0(bytes) soft: 0(bytes)
 allocated: 3832 hard: 0 soft: 0
 sadb_seq=0 pid=30197 refcnt=0

Проверяем пинг. Если он есть, и значение

diff: 2225(s)

в выводе setkey -D выше меняется, значит данные пошли внутри IPsec.

Если пинг идет, а ключевых пар нет, или если пинг не идет значит где то в конфигах IPsec ошибка. Смотрим правильность своих подсетей, пропускаем демонов и пингуем еще раз, до нужного результата.