Сайт Романа ПарпалакаБлогКлючевые словалинукс

линукс

Статьи по этой теме:
Windows vs. Ubuntu
Латех и веб-технологии


HTTPS и Letsencrypt

1 марта 2016 года, 19:42

Протокол https отличается от http передачей данных в зашифрованном виде. Обычно шифрование необходимо, когда на сайте встречаются закрытые паролем страницы. Однако есть и другие причины. Мне пришлось поддерживать https на сервисе генерации картинок с формулами на латехе, чтобы их можно было встраивать в другие https-страницы. Новый протокол HTTP/2 будет работать в браузерах только через https. А еще Гугл учитывает наличие шифрования при ранжировании.

Для нормальной работы сайта по https требуется сертификат. Центры сертификации выдают их за определенную плату после подтверждения владения доменом.

Вообще-то, добыть бесплатный сертификат можно было и раньше на сайте StartSSL, но без особого удобства. После регистрации и проверки электронной почты вы получаете сертификат для входа на сайт StartSSL. Добавляете его в браузер. Подтверждаете владение доменом через почту webmaster@example.com. Бесплатные сертификаты выдают на один домен и один поддомен сроком на год. Вы загружаете их на сервер и указываете в конфигурации веб-сервера. Для nginx нужно объединять ваш сертификат и промежуточный сертификат в один файл.

С появлением сервиса Letsencrypt процедура получения сертификатов существенно упростилась. Вы устанавливаете на своем сервере клиентское программное обеспечение для общения с сервером Letsencrypt. Чтобы подтвердить владение доменом, организуете папку, содержимое которой доступно в вебе:

location ^~ /.well-known/acme-challenge {
    alias /var/www/letsencrypt;
}

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

Срок действия сертификатов — 90 дней. Но это не проблема, потому что легко настроить повторную выдачу сертификатов автоматически, по крону, например, раз в два месяца.

Насколько я понял, wildcard-сертификаты (*.example.com) не поддерживаются. Но вы можете сформировать один сертификат на несколько поддоменов. Либо создавать сертификат на каждый новый поддомен.

Официальный клиент Letsencrypt у меня на Дебиане не заработал. При запуске он скачал и установил какие-то дебиановские пакеты. Вместо генерации сертификата выводил непонятную питоновскую ошибку, с которой я ничего сделать не смог. Поиск привел к альтернативному клиенту letsencrypt.sh на старом добром баше. letsencrypt.sh сразу заработал без проблем. Рекомендую использовать его.

Letsencrypt — замечательный сервис. Он решает проблему автоматической выдачи бесплатных сертификатов и позволяет без дополнительных усилий включить на сайте протокол https.

Ключевые слова: веб-разработка, линукс | Оставить комментарий

Debian 8

1 мая 2015 года, 11:49

Обновил Debian на виртуальном сервере до недавно вышедшей 8 версии (jessie). В целом обновление прошло гладко. С конфигурацией Nginx были проблемы. Во-первых, в ходе установки в sites-enabled включился хост «default», из-за чего оказалось два сервера по умолчанию. Во-вторых, из-за путаницы с fastcgi_params и fastcgi.conf перестал работать PHP. Отдавалась пустая страница и ответ 200, в логах пусто. Не сразу разобрался, в чем дело, потому что искал причину в конфигурации php-fpm.

Еще из-за перехода с SysV на systemd перестал запускаться svnserve. Пришлось опять вручную настраивать запуск. Для этого надо сделать файл /etc/systemd/system/svnserve.service с примерно таким содержимым:

[Unit]
Description=SVN Server

[Service]
Type=forking
User=svn
Group=nogroup
ExecStart=/usr/bin/svnserve --daemon -r /var/svn --log-file /var/log/subversion.log

[Install]
WantedBy=multi-user.target

Затем выполнить команды systemctl start svnserve и systemctl enable svnserve.

Ключевые слова: линукс | Оставить комментарий

Простое резервное копирование

3 августа 2011 года, 20:12

Давайте я вам расскажу, как работает резервное копирование (бекап) на моем сервере. Самая ценная информация хранится в базе данных. Помимо этого есть еще код движка в репозитории subversion, который бы не хотелось потерять. Их и будем архивировать.

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

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

#!/bin/bash
DATE="`date +%Y-%m-%d_%H-%M-%S`"
SVN="s2-backup_$DATE.svn.7z"
MYSQL="mysql-backup_$DATE.sql.7z"

svnadmin dump /path/to/project -q | 7za a -si -p123asd $SVN
mysqldump -ubackup -p123asd --all-databases | 7za a -si -p123asd $MYSQL

echo Backups for $DATE | biabam $SVN,$MYSQL -s "Backups $DATE" mail@example.com

[ -n "$1" ] && [ "$1" = delete ] && ( rm $SVN ; rm $MYSQL )

Сразу замечу, что «123asd» нужно заменить в каждом месте на правильный пароль.

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

В следующих двух строчках архивируем репозиторий и дамп базы данных. Тут нужно вписать правильный путь до репозитория subversion, а также имя и пароль существующего пользователя базы данных. Используемые здесь архивы 7z компактнее zip, gz и др. На архивы нужно поставить пароль подлиннее, чтобы избавиться от симптомов паранойи по поводу хранения конфиденциальной информации на серверах Гугла.

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

Последнюю строчку я добавил для управления судьбой созданных архивов после отправки письма. Чтобы их удалить, скрипт нужно вызывать с параметром delete. Этот параметр используется при автоматическом запуске скрипта с помощью cron (параметры ниже соответствуют ночному запуску два раза в неделю):

15  3   *   *   0,3  ~/backup/backup.sh delete > /dev/null

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

Вы можете взять этот пример за основу и добавить архивирование другой ценной информации.

Ключевые слова: линукс | Оставить комментарий

Проблемы открытого кода

3 октября 2009 года, 13:08

Статья «Проблемы открытого кода» (via Смирнов). Со многими вещами я согласен, но не со всеми.

Меня очень огорчает, когда я вижу всю эту молодёжь, которая думает, что Linux это круто, в то время как устройство этой системы настолько древнее, что будь она человеком, из неё давно бы песок сыпался. Им бы лучше придумывать что-то новое. Представьте себе молодого выпускника колледжа, специалиста по аэродинамике, который тратит жизнь обслуживая DC 10! (древняя модель самолетов, год выпуска – 1970). Ни один человек в мире, способный на инновации, не стал бы этим заниматься.

Почему, объясните мне, если что-то работает, причем работает хорошо, это надо обязательно выбросить под предлогом древности?

Линукс хороший, лучше него никто не может обрабатывать текстовую информацию. В том числе из-за этого он заслуженно занимает нишу серверных операционных систем.

Ключевые слова: линукс | Оставить комментарий
Поделиться
Записи