Re: параметр Exim, отвечающий за intermediate-сертификат

[Artem Chuprina]

Sohin Vyacheslav -> debian-russian@lists.debian.org  @ Fri, 5 Feb 2016 12:56:28 
+0200:

 >>  >> А отношение к делу имеют tls_certificate и tls_privatekey.  И в
 >>  >> tls_certificate не надо класть private key.  У них, собственно, и
 >>  >> права-то обычно разные.  Сертификат - публичная информация, а секретный
 >>  >> ключ - отнюдь.  А вот оба сертификата - и свой, и промежуточный - как
 >>  >> раз надо, именно в этом порядке.

 SV> я убрал ключ из exim.crt и раскомментировал строку с exim.key в
 SV> exim4.conf => всё так-же работает, визуально в логе ничего не изменилось...


 SV> в http://www.rldp.ru/exim/exim480r/glava38.htm указано:
 SV> tls_certificate =/some/file/name
 SV> tls_privatekey =/some/file/name

 SV> Это может быть один и тот же файл, если в нём содержатся сертификат и ключ.

Да.  Но поскольку степень их публичности разная, делать так вряд ли полезно.

 >> В моем случае я пользуюсь собственным CA, и у меня нет промежуточного,
 >> но разница должна быть исключительно в содержимом файла, на который
 >> указывает tls_certificate.
 >> 
 >> А глядя на конфиг на ноутбуке (на ноуте, в отличие от сервера, он у меня
 >> не ручной, а сконфигурированный через дебиановскую систему), я наблюдаю,
 >> что дефолты будут такие:
 >> 
 >> tls_advertise_hosts = *
 >> tls_certificate = /etc/exim4/exim.crt
 >> tls_privatekey = /etc/exim4/exim.key
 >> tls_verify_certificates = /etc/ssl/certs/ca-certificates.crt
 >> 
 >> (требовать клиентских сертификатов он при этом не будет, поскольку
 >> tls_verify_hosts и tls_try_verify_hosts не выставлены; но тут видно, что
 >> tls_verify_certificates - это набор сертификатов CA, которыми подписаны
 >> клиентские, что логично)
 >> 
 SV> в http://www.rldp.ru/exim/exim480r/glava38.htm также указано:
 SV> Если установлена опция tls_verify_certificates, она должна быть именем
 SV> файла или (только для OpenSSL, не для GnuTLS) каталогом, который как
 SV> ожидается содержит коллекцию серверных сертификатов.

 SV> имеется в виду не сертификат exim.crt, a ca-certificates.crt?

Точно не exim.crt (разве что ты собираешься принимать себя самого как
сетевого клиента).  Но вот насчет ca-certificates - вопрос мутный.  В
переводе слово "сереверных" - гонево.  Речь идет про _клиентские_
сертификаты.  В оригинальной документации сказано

The contents of the certificate are verified by comparing it with a list of 
expected certificates.

These may be the system default set (depending on library version),

an explicit file or, depending on library version, a directory, identified by 
tls_verify_certificates. 

Что, с одной стороны, как бы делает вид, что по списку проверяется
именно сертификат, предъявленный клиентом, а не то, что он подписан
одним из этих CA, и в этом есть логика - мало ли кто что подписал.  С
другой - ни одна из двух используемых библиотек TLS не имеет system
default set именно сертификатов самих агентов.  Имеет system default set
только сертификатов CA, возможо, только корневых и самоподписанных.
Дебиановский дефолт тут может оказаться не аргументом.

Но я все же подозреваю, что это - сертификаты CA, то есть дефолтны
дебиановский конфиг делается правильно.  В норме никто не проверяет сами
сертификаты серверов, проверяют только подпись достаточно доверенного
CA.

Re: Как переносить настройки / мигрировать на другой сервер?

[Sergey B Kirpichev]

On Sat, Feb 06, 2016 at 05:32:02PM +0200, Oleksandr Gavenko wrote:
> VPS хостер выставил тариф с условиями лучше чем сейчас.
> 
> Виртуализация на KVM. Я не представляю водможна ли миграция. Думаю есть
> автоматические инструменты у хостера, но нужно создавать тикет...

Разумеется возможна.  Бежите от такого хостера, что нагло
вам в глаза врет, что не.

> Как переносить настройки / мигрировать на другой сервер более автоматически?

По-разному.  В вашем случае, думаю что см. выше.

>  * Иерархию /srv/ можно было перенести rsync.
>Проблему вижу в перенесении прав доступа. Некторых пользователей отдельно
>создавал и давал каталог...

В принципе, rsync, запущаемый (от рута) б-м стандартным образом (ключик -a,
например) должен был перенести в точности все права доступа, uid/gid файлов.

>rsync же не делает adduser?

adduser можете ручками потом сделать.  Или тупо скопировать (sed/awk)
нестандартные вещи из passwd, shadow - так легше не перепутать
uid/gid'ы пользователей и групп.

>А если делает - то он должен запускаться от root. Не ясно как пользоваться
>от root.

А что конкретно неясно?

> При обновлении с Debian 7.0 до 8.0 - я выключил возможность ssh
>для root:  rsync -e 'ssh -l root' user@vps/...

А sudo вы тоже выключили?

Как-то так вот:
rsync -av --rsync-path="sudo rsync" ...

Ну а если лень разбираться - просто включите временно "ssh для root" взад.

>  * Иерархию /etc/ стремно переносить по rsync.

А что тут может быть стремного?  (Пакетики, конечно, установить надо
нужные сперва.)  Разве вот IP поменялись, но это уж вы там просто
разберитесь куда их напонаписали.  Теоретически, кроме /etc/network они
особо нигде не должны быть.

Как переносить настройки / мигрировать на другой сервер?

[Oleksandr Gavenko]

VPS хостер выставил тариф с условиями лучше чем сейчас.

Виртуализация на KVM. Я не представляю водможна ли миграция. Думаю есть
автоматические инструменты у хостера, но нужно создавать тикет...

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

Как переносить настройки / мигрировать на другой сервер более автоматически?

Ниже опишу производимые шаги, но основные моменты мне кажутся следующими:

 * Иерархию /srv/ можно было перенести rsync.

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

   rsync же не делает adduser? И назначать права от других пользователей не
   может.

   А если делает - то он должен запускаться от root. Не ясно как пользоваться
   от root. При обновлении с Debian 7.0 до 8.0 - я выключил возможность ssh
   для root:  rsync -e 'ssh -l root' user@vps/...

 * Иерархию /etc/ стремно переносить по rsync.

   Я ощущал уверенность только за отдельные каталоги:

 /etc/lighttpd/*
 /etc/proftpd/*
 /etc/xinet.d/*

Если rsync кажется проблемным для переноса прав доступа - то что использовать
tar?

Как безопасно переносить иерархию /etc?



Под-домены были через CNAME прописаны, проблем со сменой IP не возникло.

Сайты деплоятся через:

  make deploy SRV_NAME=... SRV_USER=...

Внутри sftp команда. Есть предварительное требование на существование
каталога, потому руками делал:

  $ mkdir /srv/www/blog
  $ mkdir /srv/www/tips
  ...

Т.е. по сути протестировал скрипты деплоя, хотя ощущаю что мог бы проделать
быстрее с rsync с рабочего сервера.

Список требуемых пакетов невелик - lighttpd, proftpd, git, hg. Установил
интерактивно через aptitude.

Настройки lighttpd мигрировал скопировав:

  /etc/lighttpd/lighttpd.conf
  /etc/lighttpd/conf-available/92-*.conf

и перечислив вручную все 92-*.conf:

  $ sudo lighttpd-enable-mod  blog tips ...
  $ sudo service lighttpd force-reload

Оплошность была в том что cgi включается отдельно, инструменты миграции
позволяют переность симлинки? (из /etc/lighttpd/conf-enabled).



Т.е. как бы нужно было:

 * знать список пакетов/версий для установки
 * перенести определеные конфиги
 * выставить нужную тайм-зону, локали
 * добавить необходимых пользователей
 * перетащить /srv/
 * применить права доступа к файлам

-- 
http://defun.work/

Re: Куда пропадают маршруты?

[Eugene Berdnikov]

On Sat, Feb 06, 2016 at 05:16:33PM +0300, Alexander Galanin wrote:
> Настроил через interfaces PPTP-интерфейс, на поднятие которого добавляю
> дополнительные маршруты:
> 
> iface ppp0 inet ppp
> provider work
> up route add -net 192.168.12.0 netmask 255.255.255.0 $IFACE
> up route add -net 192.168.115.0 netmask 255.255.255.0 $IFACE
> 
> Подключаюсь через ifup ppp0. Секунд 10 добавленные маршруты живут,
> после чего пропадают. Если добавить их заново, то на какое-то время они
> остаются, после чего могут снова внезапно пропасть.
> 
> Кто может сбрасывать маршруты, и как это отследить?

 Маршруты могут сбрасываться при обрыве связи, если pppd запускается
 с флагом persist (что логично для использования interfaces), потом
 теряет линк и реконнектится. При этом в ряде случаев интерфейс удаляется
 и создаётся заново. Отследить очень просто: включить дебаг pppd
 и почитать его.

 Вообще, так делать не следует. Все маршруты нужно поднимать скриптами
 в /etc/ppp/ip-up.d/, потому что они привязаны к интерфейсу, а не к
 процессу pppd.

 Кроме того, метод "ppp" плох тем, что может дать конфликт юнитов.
 Если уж написано "iface ppp0", я бы предложил добавить "unit 0",
 чтобы не было расхождения между тем, что ожидает ifupdown, и тем,
 что в реальности создаст pppd (а он берёт первый свободный юнит,
 если юнит не задан явно). Использование скриптов из /etc/ppp/ip-up.d/,
 которые проверяют ipparam или какую-нибудь переменную, заданную через
 set, позволяет избежать потенциального конфликта.

 Наконец, вместо pptp лучше использоваь openvpn, он секьюрнее и умеет
 передавать маршруты от сервера клиенту, без всех этих заморочек. :)
-- 
 Eugene Berdnikov

Re: Куда пропадают маршруты?

[Alexander Galanin]

On Sat, 6 Feb 2016 22:20:13 +0300
Eugene Berdnikov  wrote:

> > Кто может сбрасывать маршруты, и как это отследить?
> 
>  Маршруты могут сбрасываться при обрыве связи, если pppd запускается
>  с флагом persist (что логично для использования interfaces), потом
>  теряет линк и реконнектится. При этом в ряде случаев интерфейс удаляется
>  и создаётся заново. Отследить очень просто: включить дебаг pppd
>  и почитать его.

Да, дейсвительно маршруты пропадали одновременно с перезапуском
скриптов из ip-up.d.

>  Вообще, так делать не следует. Все маршруты нужно поднимать скриптами
>  в /etc/ppp/ip-up.d/, потому что они привязаны к интерфейсу, а не к
>  процессу pppd.

Так и сделал, работает. Спасибо!

>  Кроме того, метод "ppp" плох тем, что может дать конфликт юнитов.
>  Если уж написано "iface ppp0", я бы предложил добавить "unit 0",
>  чтобы не было расхождения между тем, что ожидает ifupdown, и тем,
>  что в реальности создаст pppd (а он берёт первый свободный юнит,
>  если юнит не задан явно). Использование скриптов из /etc/ppp/ip-up.d/,
>  которые проверяют ipparam или какую-нибудь переменную, заданную через
>  set, позволяет избежать потенциального конфликта.

Мне и самому не нравилось, что интерфейс назывался ppp0, но иначе в
interfaces я бы вообще никак его имя не получил. Сейчас использую
$IFNAME в ip-up-скрипте.

>  Наконец, вместо pptp лучше использоваь openvpn, он секьюрнее и умеет
>  передавать маршруты от сервера клиенту, без всех этих заморочек. :)

У меня нет возможности изменить VPN-сервер на удалённой стороне.

-- 
Alexander Galanin

Re: Куда пропадают маршруты?

[Леонид Кальмаев]

Я бы посоветовал сменить с $iface на via ip_gateway.

Незаконные извлечения органов в Китае. debian-russian@lists.debian.org

[Cквозь призму реалий]

debian-russian@lists.debian.org
"УПРАВЛЯЕМАЯ ГОСУДАРСТВОМ КИТАЙСКАЯ МЕДИЦИНА СТАЛА 
ПРЕДПРИЯТИЕМ СМЕРТИ"
ОТПИСАТЬСЯ
В МАРТЕ 2006 ГОДА ВСЕМУ МИРУ СТАЛО ИЗВЕСТНО И ВСКОРЕ БЕЗУСЛОВНО ДОКАЗАНО, ЧТО 
НА  ТЕРРИТОРИИ КИТАЯ РАБОТАЮТ СЕКРЕТНЫЕ ЛАГЕРЯ СМЕРТИ, ПРИНАДЛЕЖАЩИЕ 
ГОСУДАРСТВУ, В НИХ ДЕРЖАТ УЗНИКОВ СОВЕСТИ, В БОЛЬШИНСТВЕ СЛУЧАЕВ ЭТО 
ПОСЛЕДОВАТЕЛИ ПРЕСЛЕДУЕМОГО В КИТАЕ ДРЕВНЕГО УЧЕНИЯ ФАЛУНЬГУН (ИЛИ ФАЛУНЬ 
ДАФА). ЭТИХ ЛЮДЕЙ СОДЕРЖАТ В КАЧЕСТВЕ БАНКА ОРГАНОВ ЕДИНСТВЕННО  ЗА ТО, ЧТО ОНИ 
ВЕРЯТ В ПРИНЦИП "ИСТИНА-ДОБРОТА-ТЕРПЕНИЕ", И ПО ПЕРВОМУ ТРЕБОВАНИЮ РАДИ ПРИБЫЛИ 
ВЫРЕЗАЮТ У НИХ ЖИЗНЕННО ВАЖНЫЕ ОРГАНЫ. ЭТИ БЕСЧИНСТВА ПРОДОЛЖАЮТСЯ ПО СЕЙ ДЕНЬ.
В апреле 2014 года две ведущие международные организации трансплантологов 
"Всемирное трансплантологическое общество" и "Группа хранителей Стамбульской 
Декларации" написали , изданное  тогда же в журнале "Transplantation" открытое 
письмо Си Цзиньпину, лидеру КНР, назвав китайскую систему пересадки  органов 
"коррумпированной и презираемой международным сообществом" . 
Ниже помещены всего  несколько из тысяч выступлений врачей на эту тему.
Д-р Рудольф Гарсия Галлонт, один из членов  "Общества трансплантологии" 
Гватемалы август 2008 года, Сидней, Австралия:  "С тех пор как проблема изъятия 
органов у живых  последователей  Фалуньгун в Китае была поднята, "Общество 
трансплантологии» приняло меры; я просто уверен, что каждый врач, находящийся 
здесь, знает о происходящем и имеет ясное понимание этого".
Д-р Дональд Бойд, лидер шотландской Христианской партии: "Вне всяких сомнений 
преступление изъятие органов нарушает все моральные кодексы. Нет морального 
кодекса, который может оправдать эти злодеяния".
Профессор Артур Каплан, директор Центра биоэтики университета Пенсильвании, 
широко известный в медицинских кругах  в марте 2012 года выступая в 
Пенсильвании с лекцией  акцентировал внимание на чудовищных "убийствах по 
необходимости" и назвал убийства, совершаемыев Китае с целью извлечения 
органов, "жесточайшим злодеянием в сфере трансплантации органов» и «позором для 
человечества".
Датук (федеральный титул в Малайзии) д-р Хазали Ахмад, главный консультант и 
глава Отделения нефрологии госпиталя Куала-Лумпур сообщил , что правительство 
Малайзии знает о случаях незаконной трансплантации органов и что, начиная с 
2012 года, "Отделение медицинского развития" больше не выдаёт лекарства 
пациентам, которые едут  в другие страны для операций по пересадке  органов.
Габриэль Данович, доктор медицинских наук, профессор Университета Калифорнии, 
ведущий руководитель Программы пересадки почек и поджелудочной железы в УКЛА, 
предложил медицинским журналам  не публиковать поступающие из Китая работы по 
трансплантации, не допускать обсуждение  операций по пересадке органов на 
медицинских конференциях, пока  они не докажут, что  используемые ими органы не 
были изъяты у казнённых заключённых.
В разгар трансплантационного туризма в Китае бывший уйгурский врач Энвер Тохти 
рассказал о том, как сам извлекал  органы у еще живых заключенных  уйгуров в 
китайской провинции Синьцзян. Посмотреть  выступление хирурга Энвера Тохти 
можно, просто используя Google.
Джордж Вэйгель, известный старший научный сотрудник "Центра этики и 
общественной политики":  "Управляемая государством китайская медицина стала 
предприятием смерти".
Подписать ПЕТИЦИЮ против зверского извлечения органов у невинных людей можно на 
нашем сайте. 
Выразить свое мнение можно, просто написав нам. Если хотите  отказаться 
получать наши сообщения, напишите по тому же адресу, только внесите в тему 
письма слово: "Отписка ".
Редакция сайта " uncensoredchina.ru "

Куда пропадают маршруты?

[Alexander Galanin]

Всем привет!

Настроил через interfaces PPTP-интерфейс, на поднятие которого добавляю
дополнительные маршруты:

iface ppp0 inet ppp
provider work
up route add -net 192.168.12.0 netmask 255.255.255.0 $IFACE
up route add -net 192.168.115.0 netmask 255.255.255.0 $IFACE

Подключаюсь через ifup ppp0. Секунд 10 добавленные маршруты живут,
после чего пропадают. Если добавить их заново, то на какое-то время они
остаются, после чего могут снова внезапно пропасть.

Кто может сбрасывать маршруты, и как это отследить? Пробовал создавать
файл /var/log/ppp-ipupdown.log (как написано в /etc/ppp/ip-up), но
никаких полезных логов из этого файла не получил.

Система jessie, пакета systemd нет.

-- 
Alexander Galanin