Лопата в руках + puppet (2)

Посидел, подумал и понял, что ставить пакет ntp только ради его конфигурационного файла… Что то тут не правильно. Тем более, что ntpdate.service из конфигурационного файла берет только имена ntp серверов, осуществляя поиск параметра peer или server.

Поэтому, для ntpdate.service можно оставить простейший файл /etc/ntp.conf следующего содержания:
server 0.centos.pool.ntp.org
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org
server 3.centos.pool.ntp.org

Итого, нам надо удалить пакет ntp и добавить свой конфигурационный файл /etc/ntp.conf

Удалить пакет можно следующим образом:
package { ‘ntp’:
ensure => absent
}

Будет удален пакет, его конфигурационные файлы останутся на месте. Нам не надо удалять конфиги. Мы просто поменяем их содержимое.

Дальше надо будет добавить свой конфигурационный файл, убедившись, что пакет ntp не установлен, а ntpdate наоборот установлен.

Изменим класс ntpdate в файле манифеста следующим образом:
class ntpdate {
        package { ‘ntpdate’:
                ensure => installed
        }
        package { ‘ntp’:
                ensure => absent,
# Пакет, если он есть, надо удалить до того как
# будет создан файл /etc/ntp.conf
before => File[‘/etc/ntp.conf’]
        }
        # Определяем конфигурационный файл
        file { ‘/etc/ntp.conf’:
                ensure => file,
                owner  => ‘root’,
                group  => ‘root’,
                mode   => ‘0644’,
# Для создания файла необходимо наличие
# установленного пакета ntpdate
                require => Package[«ntpdate»],
                # Содержимое файла указываем прямо тут
                content => «server 0.centos.pool.ntp.org
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org
server 3.centos.pool.ntp.org
«
        }
        service { ‘ntpdate’:
                enable => true,
                ensure => running,
                require => Package[«ntpdate»],
        }
}

Проверим конфиг на ошибки:
# puppet parser validate /etc/puppet/manifests/site.pp

В результате на клиенте:

  • если установлен пакет ntp, он будет удаляться.
  • будет добавлен или изменен файл /etc/ntp.conf

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

Если конфигурационные файлы большие, включаем файловый сервер puppet или ftp сервер или … Размещаем конфиги там. Но об этом в другой раз. 

Лопата в руках + puppet

Побегал по собеседованиям и c удивлением обнаружил, что многим работодателям требуется знания по puppet. Решил за одно с разборками по CentOS 7 научиться пользоваться этим чудом автоматизации конфигурации :).

Пока создал две виртуалки:

  • centos7-1.test.local — сервер с puppet сервером на борту. На нем мы будем конфигурировать клиент.
  • centos7-2.test.local — собственно клиент, который будет все данные по своей конфигурации брать с сервера.

При установке клиента и сервера была сразу настроена сеть. DNS сервер пока не поднимался, поэтому в файле /etc/hosts на обеих машинах добавлены строки:
192.168.200.99 centos7-1.test.local  centos7-1
192.168.200.98 centos7-2.test.local  centos7-2

Маршрут по умолчанию на сервере, через хост машину. Маршрут по умолчанию на клиенте, через сервер.
Fierwall на сервере настроен. Удален fierwalld, настроен маскарадинг и доступ по ssh. На клиенте все по умолчанию.
При установке клиента выбрана минимальная конфигурация сервера.

Puppet будем конфигурить исходя из того, что у нас везде CentOS 7. Т.е. пока не будем заморачиваться с многоплатформенностью.

Установка puppet на сервер.

# rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm
# yum install puppet-server

Поскольку лениво руками возиться c сертификатами, включим автоматическое подписывание сертификатов. В реальной жизни так делать низзя.
# vim /etc/puppet/puppet.conf
[main]
    …
    autosign = true

Создадим манифест файл заглушку. По мере понимания системы, будем его расширять.
# vim /etc/puppet/manifests/site.pp
package {
  ‘mc’:
    ensure => installed;
}
Собственно тут говориться, что надо поставить пакет mc, если его еще нет.

Запускаем сервер:

# systemctl start puppetmaster.service
# systemctl enable puppetmaster.service
# systemctl status puppetmaster

Проверяем наличие открытого порта 8140 в fierwall:
# iptables -L INPUT -n —line-numbers

Если порт не открыт, добавляем:
# iptables -I INPUT 5 -p tcp -m state —state NEW -m tcp —dport 8140 -j ACCEPT
# service iptables save

Установка puppet клиента на centos7-2.

# rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm
# yum install puppet

Указываем сервер, куда буем ходить:
# vim /etc/puppet/puppet.conf
[agent]
    server=centos7-1.test.local
    certname=centos7-2-cl.test.local

Подключаемся агентом, заодно генерируя и подписывая сертификаты:
# puppet agent —test 

Если ошибок не показало, запускаем сервис:
# systemctl start puppet.service
# systemctl enable puppet.service
# systemctl status puppet

Кстати, пакет mc уже установился, программой можно пользоваться.

Переходим на сервер.

На всякий пожарный ставим средство для работы с конфигами. Чувствую, что оно нам пригодится.
# yum install augeas

Ставим библиотеку, необходимую для работы со строками.
# puppet module install puppetlabs-stdlib

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

Мне понадобятся: ssh, ntp, mc, vim (мой любимый редактор), net-tools (ip ставиться по умолчанию, но я привык к стандартному ifconfig и route), traceroute, tzdata (с обязательным обновлением до последней версии, а вдруг, не дай бог, опять дадут порулить «Повелителю Времени»?).
Так же я люблю кастомную строку приглашения.

Итого файл будет выглядеть следующим образом:
# vim /etc/puppet/manifests/site.pp

class sshd {
    # долен быть установлен пакет
    package { ‘openssh-server’:
ensure => latest
    }
    # сервис должен быть запущен
    service { ‘sshd’:
name => «sshd»,
enable => true,
ensure => running
    }
}

# Сервер ntpd поднимать не будем, ограничимся ntpdate, благо в
# CentOS 7 проверку можно запускать как сервис.
# для ее работы потребуется конфигурационный файл /etc/ntpd.conf
# который находится в пакете ntp
class ntpdate {
    # ставим пакет ntp. Ntpdate будет поставлен по зависимости.
    package { ‘ntp’:
ensure => installed
    }
    # запускаем соотвествующий сервис.
    service { ‘ntpdate’:
enable => true,
ensure => running
    }
}

# создаем базовый класс, для всех машин
class baselinux {
    package { ‘mc’: ensure => installed }
    package { ‘vim-enhanced’: ensure => installed }
    package { ‘net-tools’: ensure => installed }
    package { ‘traceroute’: ensure => installed }
    package { ‘tzdata’: ensure => latest }
    include ‘sshd’
    include ‘ntpdate’
    # необходимо для работы file_line
    include ‘stdlib’
    # Добавляем переменную PS1 в конец /etc/bashrc, если ее в этом файле еще нет.
    # Точнее говоря, PS1 там уже есть, мы контролируем наличие именно такой строки
    # и если ее нет, то добавляем в конец файла.
    file_line { ‘ps1_rule’:
        path => ‘/etc/bashrc’,
        # line пишем одной строкой
        line => ‘PS1='[e[44;36m]t:[w][e[0;0m]n[e[0;31;04m]u[e[0;0m]@[e[0;32m]h[e[0;0m] $ »
    }
}
# node по умолчанию, используется в том случае, если нет явного
# нода для конкретной машины.
node default {
    include ‘baselinux’
}

# node для клиента.
node ‘centos7-2.test.local’ {
    include ‘baselinux’
}

Node для клиента пока идентичен ноду по умолчанию. Но я буду его потихоньку добавлять.

Если лениво ждать пока на клиенте включатся наши изменения, на нем можно запустить:
# puppet agent —test 

На клиенте будут установлены все необходимые пакеты и запустятся (если ещё не были запущены) указанные нами сервисы.

Пока как то так.

Копаю CentOS 7

Пришла пора разбираться с тем, что RedHat накрутил в 7-ке.

Первое, что надо сделать — отключить fierwalld 🙂

# systemctl disable firewalld
# systemctl stop firewalld
# yum install iptables-services
# touch /etc/sysconfig/iptables
# touch /etc/sysconfig/ip6tables
# systemctl start iptables
# systemctl enable iptables
# iptables -L -n

Получаем iptables правила по умолчанию, обычные для CentOS.

Второе — придется таки изучить systemd 🙁 Если его выковырять — то это будет Slackware с системой инициализации System V. Что в принципе неплохо, но при большом количестве инсталляций будет трудноуправляемо.

Thunderbird, sendmail и dh key too small

Обновился Тандерберд до версии 31.8.0 и перестал работать SSL при отправке почты на моем сервере.
При проверке сертификата на сервере, получаю ошибку
openssl s_client -connect smtp.local.local:25 -starttls smtp

140195198617232:error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3339:

Да, я лопух, не позаботился о закрытии дырки в SSL. Впрочем, кому нужно ломать SSL при отправке почты через этот сервер, учитывая, что аутентификация клиентов идет не по сертификатам?
Ну да ладно.
В новой версии библиотеки nss, жестко ограничили длину:

  • The minimum modulus size for RSA keys is now 512 bits
  • The minimum modulus size for DSA keys is now 1023 bits
  • The minimum modulus size for Diffie-Hellman keys is now 1023 bits

Решение для sendmail.
Генерируем DH файл параметров.
openssl dhparam -out /etc/pki/tls/certs/dhparams.pem 2048

Важно! Длинна должна быть не меньше, чем 1024, но на всякий пожарный я выбрал 2048. А вдруг они потом изменят свое решение в сторону увеличения?

Поскольку для тонкой настройки SSL (выбора чиперов) нет макросов m4, в файле sendmail.mc, в самом конце добавляем секцию LOCAL_CONFIG и в ней пишем соответствующие параметры:

LOCAL_CONFIG
O CipherList=HIGH:!ADH
O DHParameters=/etc/pki/tls/certs/dhparams.pem

Собственно используем тока эти чиперы:
# openssl ciphers -v ‘HIGH,!ADH’

sendmail + dovecot

Как говориться: «давно не брал я в руки шашку»

Намедни скрещивал sendmail c dovecot.
Раньше между MDA и dovecot была прослойка антиспама DSPAM. Но производитель перестал осуществлять поддержку и пришлось с этой прогой попрощаться. Причем у довекота свое хитрое хранилище почты, никоим образом не пересекающееся с домашними директориями пользователей. База пользователей хранится в LDAP, поиск пользователя по uid без домена.  Т.е. они там просто vasia, petia, а не vasia@domen.com и т.п.
По этой причине стандартные «быстрые» howto не подошли.
Пример из официального руководства http://wiki2.dovecot.org/LDA/Sendmail не работал. После преобразования имен sendmail упорно выдавал пользователя с доменом локальной машины. Т.е. на входе преобразования petia@virt.domain.com, на выходе petia@host.com
Проблема решается путем удаления флага h и замены правила EnvToSMTP на PseudoToReal.

В результате получился вот такой m4

######################################################################
# to user = user@domain.com  use  F=DFMPhnu95l
# to user = user   use  F=DFMPnu95l
Mdovecot,   P=/usr/libexec/dovecot/dovecot-lda, 

            F=DFMPnu95l,
            S=EnvFromSMTP/HdrFromSMTP,

            R=PseudoToReal/HdrFromSMTP,
            T=DNS/RFC822/X-Unix,
            A=/usr/libexec/dovecot/dovecot-lda -d $u

sendmail.mc содержит:

define(`confLOCAL_MAILER’,`dovecot’)dnl
MAILER(dovecot)dnl

И самое смешное, после того как все это начало работать, я подумал: » а зачем так сложно?» и прикрутил sendmail к dovecot через LMTP 🙂 Тем более что в howto было написано: Best solution is to use LMTP instead 🙂 Но к сожалению эта фраза попалась мне только после окончания прикручивания своего мейлера 🙁

FEATURE(`local_lmtp’,`[IPC]’,`FILE /var/run/dovecot/lmtp’)dnl
MAILER(local)dnl

Майлер local по автомату не подставляет имя хоста.

Mikrotik — Wi-Fi bridge Ethernet — 100% CPU load

Микротик в прошивке 5.24 починил баг, связанный со 100% загрузкой процессора при объединении мостом Wi-Fi и Ethernet чипа.
Так что обновляемся.

nxserver, ubuntu, не отображается меню

Настраивал тут nxserver товарищу, нарвался на то, что при входе пользователя не рисуется рабочий стол. Как я и подозревал, во всем виноват compiz 🙂 нечего 3D плюшки по сети гонять! Вот nx и не гоняет. В результате у пользователя нет рабочего стола.

Решение проблемы простое, запускать сессию пользователя в 2D режиме. Ищем файл node.cfg, изменяем параметр.
CommandStartGnome = «/usr/bin/gnome-session —session=ubuntu-2d»
Все довольны.

Предчувствие gentoo.

Предчувствую, что gentoo станет моим любимым дистрибутивом. Причина вот в этом: Команда Gentoo Linux планирует совершить форк проекта udev.

Прямо как в любимом фильме: «я такую неприязнь испытываю к systemd, что аж кушать не могу» 🙂

Mikrotik и BeeLine

У моего старого домашнего провайдера начались проблемы. Причем эти проблемы приобрели регулярность. Решил попробовать домашний итернет от пчелайна.
Из-за особенностей организации сети пчелайна и фич микротика, подружить их между собой достаточно тяжело. Добрые люди написали толковый мануал, огромно спасибо им за это. Но, как обычно, в жизни не все так как в мануале 🙂 Учитывая, что старый провайдер пока от микротика не отключается, провод пчелайна был засунут в отключенный от общего свича интерфейс (ether5), появились маленькие тонкости.

1. Сначала подключитесь виндовым клиентом напрямую к сети  пчелок и запишите ip адреса DNS и VPN серверов пчелайна.

2. Почему то пчелайн DHCP сервер не отдает микротиковскому клиенту маршрут по умолчанию. Виндовому клиенту дает, микротику не дает. Поэтому приходится прописывать маршруты к сетям где находятся DNS и VPN серверам руками. Да и вообще, какой то странный их DHCP, выдал кучу всяких маршрутов, кроме вышеуказанных! Ну и по поводу его странности, см. следующий пункт.

3. Пчелайн редкосные бяки, их DHCP сервер выдает вот такой вот маршрут:
#      DST-ADDRESS  PREF-SRC  GATEWAY    DISTANCE
1 ADS  10.0.0.0/8             10.89.48.1 1
У моего старого провайдера внутренняя сеть тоже 10, но с маской /16. Т.е. старый провайдер честно дает маршрут на часть сети. Благо там pppoe подключение и можно не получать IP на интерфейс. Но пчелайн своим чудо маршрутом, просто заставил меня отказаться от использования внутренней сети старого провайдера. А там есть разные вкусности.

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

corbina-l2tp_refresh
:local interface «BeeLine-l2tp»
:local vpnserver «tp.internet.beeline.ru»
:log debug message=»Hard resolv script run»
/ip dns cache flush
:local «current-ip» [:resolve $vpnserver]
:local «old-ip» [/interface l2tp-client get [/interface l2tp-client find name=»$interface»] connect-to]
:if ($»current-ip» != $»old-ip») do= {
:log info «VPN Server changed IP address from $»old-ip» to $»current-ip»»
/interface l2tp-client set [/interface l2tp-client find name=»$interface»] connect-to=$»current-ip»
}

corbina-l2tp_soft_refresh
:local interface «BeeLine-l2tp»
:local vpnserver «tp.internet.beeline.ru»
#:log debug message=»Soft resolv script run»
:if ([/interface l2tp-client get $interface running] = false) do={
:log info message=»VPN down. Refreshing»
/ip dns cache flush
:local «current-ip» [:resolve $vpnserver]
:local «old-ip» [/interface l2tp-client get [/interface l2tp-client find name=»$interface»] connect-to]
:if ($»current-ip» != $»old-ip») do= {
:log info «VPN Server changed IP address from $»old-ip» to $»current-ip»»
/interface l2tp-client set [/interface l2tp-client find name=»$interface»] connect-to=$»current-ip»
}
}

Разумеется вместо BeeLine-l2tp вы подставите свое имя l2tp интерфейса.

З.Ы. Очень понравились возможности микротика в части управления чипа свича! Для начала сформировал два интерфейса в отдельный свитч (смотрите параметр Master Port на интерфейсе). В один воткнул шнур от пчелок, в другой шнур идущий на кухню. Таким образом смог подключить ноут на прямую в сеть пчелок. Записал все необходимые параметры, вернул интерфейс в старый свич. Если бы этой возможности не было, пришлось бы на табуретке сидеть в коридоре 🙂

Ай да mikrotik, а да сукин сын.

Ну ребята, таки mikrotik меня удивил. Нда, я давно так не удивлялся. Такое ощущение, как будто съел кучу васаби и тебе сразу прочистило все дыхательные пути.

Итак: есть как бы роутер на микротик, у него два интерфейса:

  1. eth1 192.168.0.100
  2. eth2 192.168.1.100

Маршрут по умолчанию через eth1 на другой роутер.
И микротик и роутер двумя интерфейсами подключены к обеим сетям: 192.168.0.0/24 и 192.168.1.0/24
Причем у микротика eth2 — это было временное подключение, только на стадии первичной конфигурации, так как рабочая станция с которой он первоначально конфигурился была в сети 1.0.

А теперь вопрос: если на микротике из интерфейса eth2 вытащить шнурок, сможете ли вы с машины, находящейся в сети 192.168.1.0/24 попасть на 192.168.0.100?
Или немного другой вариант вопроса: можете ли вы, находясь на микротике попасть в сетку 192.168.1.0/24 согласно его маршрута по умолчанию?

Ответ простой — нет!

Как оказалось, у RouterOS есть забавная фишка. У нее маршруты к сетям, подключенным к интерфейсу, при отключении линка из таблицы маршрутизации автоматически не удаляются! О как! В Linux удаляются (кстати все маршруты проходящие через этот интерфейс), в Windows удаляются, а в RouterOS нет!

И вот, три дня я нем мог понять, почему с упорством маньяка RouterOS пытается отсылать пакеты в интерфейс, на котором нет линка?

Слава богу служба поддержки Микротика работает отлично и они меня просветлили (именно просветлили, прямо таки карму почистили).

Для того, что бы интерфейс начал работать в привычном, например для меня, режиме. Нужно добавить небольшой фильтр.

[admin@MikroTik] > /routing filter print
Flags: X — disabled
0   chain=connected-in prefix=192.168.1.0/24 scope=200 invert-match=no
action=reject set-bgp-prepend-path=»»

Принцип работы этого фильтра: если есть лик, значение scope=10, если линк down — то scope=200.

Немного поработав с mikrotik девайсами я догадываюсь почему у них так устроено 🙂 но все равно — это было очень неожиданно.

Небольшой апдейт. Достаточно удалить ip адрес из списка и маршрут будет удален. Но если его не удалить руками, то да — пишем фильтр.