pc_mania

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

В связи с этим, были произведены некоторые изменения в конфигах Apache:

1. Были прописаны сертификаты
2. По умолчанию прописанный Location, я заменил на Directory, добавив два параметра

<VirtualHost *:443>
    DocumentRoot /var/hg/

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/file.cert
    SSLCertificateKeyFile /etc/apache2/ssl/file.key
    SSLCACertificateFile /etc/apache2/ssl/file.cert
    SSLCARevocationFile /etc/apache2/ssl/file.crl

    WSGIScriptAlias / /var/hg/hgweb.wsgi

    <Directory>
        AuthType Basic
        AuthName "Mercurial repositories"
        AuthUserFile /var/hg/hgusers
        Require valid-user
        SSLVerifyClient optional
        SSLOptions +FakeBasicAuth
    </Directory>

</VirtualHost>

Параметр SSLVerifyClient optional позволяет не обязательно использовать сертификат. При таком подходе, при установлении соединения с Apache, браузер будет предлагать использовать сертификат. И, если последний не установлен, разрешит работать без него.
Параметр SSLOptions +FakeBasicAuth эмулирует базовую аутентификацию Апача, реализуемую обычно посредством файлов типа htpasswd. В этом случае, файл все-таки будет использоваться, только вместо имени пользователя, надо хранить в файле параметры, зашитые в сертификат при его создании. Получить требуемую строку можно командой:

openssl x509 -noout -subject -in /etc/apache2/ssl/client-certs/client_certificate_1.crt

Результат работы команды будет примерно такой:

subject= /C=RU/ST=Moscow/L=Kolomna/O=pc-mania/OU=IT/CN=pc-mania/emailAddress=user@domain.org

Все, что будет после subject= и есть требуемая строка.

Далее надо зашить эту строку в файл /var/hg/hgusers, прописанный у нас в конфиге. Зашивать надо так:

/C=RU/ST=Moscow/L=Kolomna/O=pc-mania/OU=IT/CN=pc-mania/emailAddress=user@domain.org:xxj31ZMTZzkVA

То есть, берем эту строку, вставляем ее в новую строчку файла, ставим после двоеточие и добавляем xxj31ZMTZzkVA. Последнее удивительное сочетание символов есть ни что иное, как md5 от слова password. Это, по всей видимости, константа, так как к паролю, собственно, сертификата не имеет никакого отношения.
При этом, по-прежнему, можно в этом файле использовать стандартные пароли типа

user:xxj31ZMTZzkVA

Пользователи смогут войти на сайт по простому паролю, а также, при помощи сертификата, не вводя пароль.

Осталось только настроить клиент Mercurial-а, чтобы он передавал эти данные серверу:
Ищем файл mercurial.ini. В Windows 7 он располагается по пути примерно такому: c:\users\пользователь\mercurial.ini. У меня такого файла не было - пришлось создавать.

[auth]
    rep1.prefix = secure.example.org
    rep1.key = path/to/file.key
    rep1.cert = path/to/file.cert
    rep1.schemes = https

В примере:

• rep1 - наименование репозитория. Используется только для того, чтобы объединить несколько параметров в одну группу, если надо прописать несколько репозиториев сразу.
• prefix - адрес сервера, хранящего репозиторий.
• key - путь к приватному пользовательскому ключу
• cert - путь к пользовательскому сертификату

Прекрасная статья. Подписываюсь под каждым словом.
http://www.cnews.ru/reviews/index.shtml?2011/04/28/438438

Девайсы пошли со здоровым разрешением... Купил себе Samsung Galaxy Tab, так эмулятор этого девайса на компе не помещается в моем мониторе. Приходится уменьшать в размерах. А Eclipse не запоминает вручную введенные настройки. Беда... Пришлось гуглить. :)
Открываем меню Run - Run configutations. В диалоге открываем вкладку Target и в строке Additional emulator copmmand line options  встлавляем строку -scale 0.57. Проблема решена. :)

Вчера я имел сомнительное удовольствие разбираться с тем, почему у меня отказывается устанавливаться пятый debian. (Почему пятый: проект заточен под эту версию ОСи. Ловить баги на продакшене не стоит и миграцию, поэтому, будем осуществлять после всестороннего тестирования проекта на новой версии операционки)

Итак, симптомы:
При установке, после ввода паролей рута, когда система начинает ставить пакеты, процесс установки стопорится на значении в 1%.

Замечания:
В четвертой (кажется) консоли отображается гениальная надпись (ставить надо только на английском языке - по-русски прочитать не получится) о том, что производится попытка установить недоверенный пакет - linux kernel версии 2.6.26. И что это может повредить компу. Надо либо yes написать, либо no. Но на клавиатуру, при этом, не реагирует. Понимать это следует так: вышло новое ядро и старое, которое есть в дистрибутиве, "отозвали". А поскольку сообществу разработчиков поддерживать версию 5 уже не интересно - они ж шестую уже отрелизели, это уже не их, а моя проблема.

Решение:
А вот решение, как раз, очень простое: надо отключить сеть при установке. Проверить подпись у пакета установщик тогда не сможет и нормально поставит базовую систему. Разумеется для этого надо иметь полноценный дистрибутив, а не netinst.
Да, и еще после установки, придется прописать сетевуху в /etc/network/interfaces вручную (либо в процессе установки дать ей статический IP).

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

Для решения этой проблемы, я решил использовать Master-Master репликации. Как оказалось, настроить их не так уж и сложно.
Предположим, что база, которую мы хотим реплицировать называется rep_db, сервер 1 имеет IP 192.168.0.1, а сервер 2 имеет IP 192.168.0.2

1. Ставим MySQL на оба сервера.


2. На обоих серверах в /etc/mysql/my.conf комментируем параметр bind-address


3. Перезапускаем мускуль.


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



5. Дальше реализуем репликацию с сервера 1 на сервер 2:
   
   
   
   • На сервере 1 правим /etc/mysql/my.conf. Должен содержать параметры:
     

     
     server-id = 1                          #уникальный, в пределах кластера, идентификатор сервера
     log_bin = /var/log/mysql/mysql-bin.log #определяет место, в которое будет сливаться бинарный лог
     max_binlog_size = 100M                 #максимальный размер бинарного лога
     binlog-do-db=rep_db                    #база, которую надо реплицировать
     binlog-ignore-db=mysql                 #база, которую не надо реплицировать
     binlog-ignore-db=information_schema    #база, которую также не надо реплицировать.
     
     

     
      
   
   
   • 
     Создаем пользователя, под которым сервер 2 будет заходить на сервер 1 за данными репликации:
     

     
     grant replication slave on *.* to 'replication'@'192.168.0.2' identified by 'slave';
     

     
      
   
   
   • Перезапускаем мускуль на сервере 1.
   
   
   • Теперь правим /etc/mysql/my.conf на сервере 2. Должен содержать параметры:
     

     
     server-id = 2                          #уникальный, в пределах кластера, идентификатор сервера
     master-host = 192.168.0.1              #адрес сервера 1
     master-user = replication              #имя созданного нами пользователя на сервере 1
     master-password = slave                #его пароль
     master-port = 3306                     #порт сервера
     

     
     
   
   
   • Рестартуем мускуль на сервере 2.
   
   
   • В консоли мускуля выполняем команду:
     

     
     mysql> start slave;
     

     
     
   
   
   
   



6. Проверяем:
   
   
   
   • в той же консольной утилите mysql на сервере 2 выполняем команду
     

     
     mysql> show slave status\G;
     
     *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: 192.168.0.1
                     Master_User: replica
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: MASTERMYSQL01-bin.000009
             Read_Master_Log_Pos: 4
                  Relay_Log_File: MASTERMYSQL02-relay-bin.000015
                   Relay_Log_Pos: 3630
           Relay_Master_Log_File: MASTERMYSQL01-bin.000009
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes
                 Replicate_Do_DB:
             Replicate_Ignore_DB:
              Replicate_Do_Table:
          Replicate_Ignore_Table:
         Replicate_Wild_Do_Table:
     Replicate_Wild_Ignore_Table:
                      Last_Errno: 0
                      Last_Error:
                    Skip_Counter: 0
             Exec_Master_Log_Pos: 4
                 Relay_Log_Space: 3630
                 Until_Condition: None
                  Until_Log_File:
                   Until_Log_Pos: 0
              Master_SSL_Allowed: No
              Master_SSL_CA_File:
              Master_SSL_CA_Path:
                 Master_SSL_Cert:
               Master_SSL_Cipher:
                  Master_SSL_Key:
           Seconds_Behind_Master: 1519187
     1 row in set (0.00 sec)
     

     
     
     На сервере 1 можно посмотреть статус мастера. Будет примерно так:
     

     
     mysql> show master status;
     +------------------------+----------+--------------+--------------------------+
     | File                   | Position | Binlog_Do_DB | Binlog_Ignore_DB         |
     +------------------------+----------+--------------+--------------------------+
     |MysqlMYSQL01-bin.000008 |      410 | rep_db       | mysql,information_schema |
     +------------------------+----------+--------------+--------------------------+
     1 row in set (0.00 sec)
     

     
     
   
   
   
   



7. Теперь реализуем репликацию из сервера 2 в сервер 1.
   
   
   
   • На сервере 2 добавляем в /etc/mysql/my.conf параметры:
     

     
     log_bin = /var/log/mysql/mysql-bin.log #определяет место, в которое будет сливаться бинарный лог
     max_binlog_size = 100M                 #максимальный размер бинарного лога
     binlog-do-db=rep_db                    #база, которую надо реплицировать
     binlog-ignore-db=mysql                 #база, которую не надо реплицировать
     binlog-ignore-db=information_schema    #база, которую также не надо реплицировать.
     

     
     
   
   
   • 
     Создаем пользователя на сервере 2, под которым будет подключаться сервер 1:
     

     
     mysql> grant replication slave on *.* to 'replication'@'192.168.0.1' identified by 'slave2';
     

     
     
   
   
   • 
     На сервере 1 добавляем в /etc/mysql/my.conf параметры:
     

     
     master-host = 192.168.0.2             #адрес сервера 2
     master-user = replication             #имя, только что созданного, пользователя на сервере 2
     master-password = slave2              #его пароль
     master-port = 3306                    #порт сервера
     

     
     
   
   
   • Рестартуем оба мускуля
   
   
   • На сервере 1 выполняем команду:
     

     
     mysql> start slave;
     

     
     
   
   
   
   


8. Проверяем
   
   
   
   

   • 
     mysql> show master status;
     

     
     На обоих серверах. Результат вывода аналогичен вышеприведенному.
     
   
   

   • 
     mysql> show slave status\G;
     

     
     На обоих серверах. Результат вывода аналогичен вышеприведенному.
     
   
   
   
   

Можно еще проверить как работает репликация, изменяя и сверяя данные на каждом сервере.

Следует также обратить внимание на параметры /etc/mysql/my.conf:

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


• 
  slave-net-timeout - количество секунд, которое слейв будет ожидать данных от мастера, прежде чем признает соединение разорванным и попытается соединиться снова. По умолчанию установлено в 3600 секунд (один час).
  


• 
  master-connect-retry - количество секунд между попытками соединиться, если соединение отвалилось по таймауту slave-net-timeout.
  

То есть, если оставить последние два параметра дефолтными, то при смерти одного из серверов, второй получит с него данные только через час. Я проставил параметры так:

slave-net-timeout = 60
master-connect-retry = 10

На компе, с которого надо заходить ssh-ем в другой комп, выполняем команду

ssh-keygen -t rsa

она запросит ряд параметров - в качестве ответа отлично подходят значения по умолчанию. пароль я оставляю пустым.

Далее на этой же машине запускаю команду

ssh-copy-id -i ~/.ssh/id_rsa.pub user@remotehost

которая скопирует публичный сертификат с этой машины на remotehost под учеткой user. Если ssh-имся первый раз, то система предложит еще добавить запись в known_hosts. Кроме того, обязательно будет запрошен пароль к удаленному компу.

( Примечания )

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


Как сделать запрос сертификата к центру сертификации:

Генерим ключ. Оно запросит пароль.

openssl genrsa -des3 -out [name_of_your_certificate].key 2048

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

openssl req -new -key [name_of_your_certificate].key -out [name_of_your_certificate].csr

Затем отправляем этот запрос в центр сертификации и ждем от них сертификат.
Когда он придет - надо отучить ключ от пароля. Иначе Apache будет запрашивать его при каждом рестарте.
Сделать это можно так (я на всякий случай делаю перед этим резервную копию сертификата и ключа):

После этого можно подключать сертификат к апачу.

Замечательная это вещь, VMWare ESXi. Одна беда: в версии 4.0 нельзя подключить к виртуалке USB устройство или COM-порт, например. Не то, чтобы я от этого сильно страдал, но как-то напрягало немного. И вот, наконец-то вдвоем с товарищем решили обновить сервак.

Следует сказать, что для этой процедуры надо обязательно затушить все виртуальные сервера на хост-сервере. А еще бэкапы снять. На всякий случай.

Для начала, с сервера VMWare был скачан файл с обновлением upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip, а также версия 4.1 vSphere Client-а. Последний был установлен на одном из клиентских компов. После скачивания надо обязательно проверить MD5 zip-файла. Я это делал утилиткой http://www.etree.org/cgi-bin/counter.cgi/software/md5sum.exe А то один раз оно не до конца скачалось.

Попробовали использовать vSphere Host Update Utility (установился вместе с новым клиентом), но как оказалось, обновлять он ничего не хочет (выдал ошибку "Failed to read the upgrade package metadata: Could not find file 'C:\Users\***\AppData\Local\Temp\3uzgmebg.pgz\metadata.xml'") и придется делать это руками. Мы совершенно не расстроились, так как за долгое время пользования всякими линуксами на такое "западло" выработался неплохой иммунитет.

Для обновления руками архив с обновлением надо залить на хост-сервер. Оказалось, что обновленный клиент сферы делать это не очень хочет. Вероятно потому, что версия сервера была еще 4.0. Хорошо, что на другом клиентском компе оставалась старая версия клиента. С ее помощью и залили на datastore этот файл.

С клиента перевели хост в maintenance mode.

Далее надо было зайти на хост-сервер ssh-ем или с консоли.
На одном из серверов был отключен ssh. ( Пришлось включать: )
Зашли через ssh и выполнили команду
esxupdate --bundle=/vmfs/volumes/Datastore1/upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip info
чтобы проверить файл установки. Система задумалась и выдала информацию по файлу. Значит все в порядке и можно обновлять.
Запустили обновление командой:
esxupdate --bundle=/vmfs/volumes/Datastore1/upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip update
Подождали пока все обновится. Перезагрузили сервак с ssh-консоли.
Дождались пока перегрузится и с консоли сервера включили вход на локальную консоль и на ssh. В версии 4.1 не требуется такой бубен как в 4.0 :)
Зашли клиентом 4.1 на сервак и вывели его из maintenanse mode. После чего повключали виртуалки.

Процесс завершен. Можно подключать USB-девайсы. :)

Вообще, нормальный подход у VMWare: "подсадить" пользователей на свой бесплатный продукт, а когда им понадобится увеличение мощности с кластеризация, предложить платное расширение возможностей. Для небольших компаний и для тестирования - идеальный вариант.

Вчера съездил с другом и коллегой в одном лице в столицу. Целью было посетить третью, проводимую в России, конференцию разработчиков СУБД Firebird и Interbase. http://ibase.ru/conf2010/index.html Мы ведем разработки под firebird и решили посетить это мероприятие в свете предстоящего выхода стабильной версии 2.5 в октябре, то есть, в течение следующего месяца. Входной билет на конференцию стоил 2478 деревянных. Редкий случай, когда я сам, уговорил руководство своей организации заплатить за то, чтобы мне в течение рабочего дня рекламировали какие-либо товары или услуги. Вообще говоря, это шикарный рекламный ход: ведь обычно за рекламу платит рекламодатель и пытается, во что бы то ни стало, донести эту рекламу до целевой аудитории. А тут - совсем другой расклад. И целевая аудитория сама пришла и даже денег заплатила за то, чтобы ей еще и что-то рекламировали. :)


( Подробный рассказ... )

Шестнадцать докладов. Все мы не выдержали. Дождались доклада Филиппе Маковски "Firebird and Linux" (единственный приличный доклад, ориентированный на разработчиков) и расстроенные поехали домой.

Резюме:
1. Ехать на четвертую конференцию, посвященную этой тематике не собираюсь категорически. Делать там нечего. Совсем. Интернет пока дает больше ответов на вопросы по этой тематике как для разработчика, так и для технического директора или руководителя проекта. Просто потеря времени и денег.
2. Будущее Interbase-а представляется мне достаточно спокойным и нормальным. А вот будущее Firebird-а с таким подходом к разработке представляется весьма сомнительным. Да это и не удивительно.

Общая проблема у OpenSource-продуктов в том, что разработчики иногда делают так как им кажется правильным, а не так, как это требуется рынку. Взять хотя бы систему ролей пользователей в Firebird 3.0. Так и вижу себе ситуацию, когда в ИТ-отдел приходит заявка от руководства добавить прав пользователю Иванову, который в бухгалтерии работает, чтобы он мог еще и финансовым аналитиком, например, поработать. Сисадмин, получив заявку, добавляет пользователя еще в одну группу в домене и заявку закрывает, после чего получает новую "Пользователь Иванов не может войти в корпоративное приложение, работающее с базой". Действительно, не сможет. Концепция "одному пользователю - одна роль" тут будет поддержана полностью. Если при trusted-аутентификации под виндой, пользователя прописать в две группы, а каждой группе назначить по роли, пользователь вообще в базу не войдет. Никак. Пока ему отдельную группу не сделают. Или персонально в базе не пропишут. Это, дескать, четко соотносится с какой-то версией стандарта SQL, расширять которую никто, похоже, не хочет. То, что на дворе 2010 год и требования к ПО, в том числе к СУБД несколько изменились - никого из разработчиков, видимо, не волнует.
Вот поэтому в СУБД, которые, менее щепетильно относятся к стандартам и не считают зазорным расширять стандарт, находятся, что называется, "на коне", а firebird так и остается базой для не очень сложных проектов. Жаль. Задумка-то неплохая...