пятница, 20 сентября 2013 г.

Справочник рабочих дней для Астериска

Долго искал способ как настроить Астериск правильно учитывать праздничные дни и перенесенные выходные. Пришел к выводу, что лучше всего - база данных с занесенным в неё официальным производственным календарем. Поскольку многие встречаются с подобной проблемой, думаю такой календарь рабочих дней будет полезен.

Справочник доступен по адресам api1.vasha-ats.ru и api2.vasha-ats.ru. Запросы, естественно, принимаются через http. Строка запроса следующая.

/daytype.php?date=<yyyy-mm-dd>&friday=1&celebration=1

Все параметры не обязательные.
  • date - дата, о которой нужно получить информацию. Если не указывать, берется текущая дата по московскому времени. На данный момент в базу занесен календарь на 2013 и 2014 год.
  • friday - отделять пятницы от обычных рабочих дней. У многих по пятницам график работы отличается от обычных дней. Если указать этот параметр (не важно с каким значением), то в пятницу будет возвращаться "4", если не указывать - "0".
  • celebration - отделять праздники от выходных дней. Если его указать, то в праздники будет возвращаться "3", если не указывать - "1", как в обычный выходной день. Актуально для тех, кто работает по выходным, но не работает в праздники.
В ответ на полученный запрос должны вернуться две строчки

Date: YYYY-MM-DD\n
DayType: X\n

Я думаю, значение Date объяснять не надо. Его можно использовать для контроля.
Значение DayType одно из следующих.
  • 0 - рабочий день,
  • 1 -  выходной день,
  • 2 - предпраздничный день,
  • 3 - праздничный день, если в запросе был параметр  celebration,
  • 4 - пятница, если в запросе был параметр friday.

Мысли о том, как проще пользоваться этим API будут приведены в следующей статье.

P.S. Если кому-то этот сервис помог сэкономить время, нервы, средства, буду рад пожертвованиям на Яндекс.Кошелек 41001771457230

среда, 21 августа 2013 г.

Попытался поставить qutim из исходников на Centos 6. Долго бился над сообщением The CXX compiler identification is unknown и, как следствие, your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found. Установка переменной не помогла.
Оказалось, не доставился пакет gcc-c++ (C++ support for GCC). Причем поиск по C++ его не находил :-(

суббота, 20 июля 2013 г.

Получение, установка и проверка SSL сертификата, подписанного StartSSL

1. Необходимо доказать права на управление доменом.

Идем в Validation Wizard, выбираем валидацию домена и получаем письмо на postmaster@домен с кодом проверки. Валидация действует 90 дней, после чего валидацию необходимо повторить, если необходимо.

2. В Certificates Wizard выбираем Web Server SSL/TLS Certificate.

Вводим полностью доменное имя, для которого нужно сгенерировать сертификат. Можно ввести до пяти доменных имен на один сертификат, что полезно когда не поддерживаются виртуальные хосты, например на почтовом сервере.
Генерируем файл запроса сертификата (CSR) openssl req -newkey rsa:2048 -keyout ssl.key -out ssl.csr . Содержимое ssl.csr вставляем в текстовое поле на странице. Нажимаем "Submit", в ответ получаем архив с набором сертификатов под различные нужды.
При генерации файла запроса сертификата создается закрытый ключ ssl.key, защищенный паролем, без которого набор сертификатов бесполезен. Поэтому необходимо сделать его резервную копию и не забыть пароль.

3. Устанавливаем сертификаты.

Так как наш закрытый ключ защищен паролем, и вводить его каждый раз при запуске сервера сложно, необходимо пароль снять. Для этого выполняем команду openssl rsa -in ssl.key -out ssl.key , сохраняем измененный закрытый ключ в специальной папке (на CentOS 6 это /etc/pki/tls/private/) и проверяем права доступа к нему (типично доступ должен быть только у рута на чтение).

Для работы многих программ (lighttpd, dovecot, postfix) необходим единственный файл сертификата, содержащий все промежуточные сертификаты. Он делается простой конкатенацией сертификатов из архива OtherServer: cat 2_домен.crt 1_Intermediate.crt root.crt >/etc/pki/tls/certs/server.pem .

3.1. Настройка Апача.

В Апаче сертификаты описываются следующими параметрами конфигурационного файла.
SSLCertificateKeyFile /etc/pki/tls/private/ssl.key # наш закрытый ключ, незащищенный паролем
SSLCertificateFile /etc/pki/tls/certs/ssl.crt # файл из архива сертификатов для Апача с именем 2_домен.crt
SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt # файл из архива сертификатов для Апача с именем 1_root_bundle.crt
Не забываем проверить остальные настройки SSL, какими они должны быть подробно описано в Интернете.

3.2. Настройка Postfix

В Postfix'е за SSL-сертификаты отвечают следующие параметры конфигурационного файла main.cf.
smtpd_tls_cert_file = /etc/pki/tls/certs/server.pem # созданный объединением сертификатов из архива OtherServer
smtpd_tls_key_file = /etc/pki/tls/private/ssl.key # наш закрытый ключ, незащищенный паролем
Также для работы шифрования должны быть установлены следующие параметры
smtpd_tls_security_level = may
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
tls_random_source = dev:/dev/urandom

3.3. Настройка Dovecot

В Dovecot'е за SSL-сертификаты отвечают следующие параметры конфигурационного фала.
ssl_cert = </etc/pki/tls/certs/server.pem
ssl_key = </etc/pki/tls/private/ssl.key
Также для работы шифрования необходимо установить параметр
ssl = required

3.4. Настройка Lighttpd

В Lighttpd цепочка сертификатов и закрытый ключ объединяются в один файл cat /etc/pki/tls/private/ssl.key /etc/pki/tls/certs/server.pem >/etc/pki/tls/private/lighttpd.pem (не забываем про права доступа к файлу).
И прописывается в конфигурационном файле в параметре ssl.pemfile = "/etc/pki/tls/private/lighttpd.pem"
Нужно не забыть включить ssl параметром ssl.engine = "enable"

4. Проверяем сертификаты.

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

Для проверки корректности шифрования необходимо выполнить команду: openssl s_client -showcerts -connect localhost:443. В ответ должны получить что-то типа Verify return code: 0 (ok).
Если для запуска шифрования необходима команда STARTTLS, то проверка будет запускаться таким образом: openssl s_client -starttls smtp -showcerts -connect localhost:25

При выполнении проверки мне встречались такие ошибки. Verify return code: 20 (unable to get local issuer certificate) и Verify return code: 21 (unable to verify the first certificate). Они говорит о том, что openssl не знает, где взять ключи издателей. Нужно ему подсказать, добавив ключ -CApath /etc/ssl/certs или -CAfile /usr/share/curl/ca-bundle.crt, у меня они нашлись в этом файле.

Команда openssl с опцией -showcerts показывает сертификаты в закодированном виде. Чтобы увидеть их содержимое можно использовать команду openssl x509 -noout -text -startdate -enddate -in /tmp/cert, где /tmp/cert - файл, в котором сохранен закодированный сертификат.

Для проверки надежности шифрования можно воспользоваться сервисом Qualis SSL Labs