02 Сентября 2016 15:12

Oracle Client вместе с PHP-FPM

PHP Oracle Linux

PHP-FPM

Достаточно часто встречается связка Nginx + PHP-FPM, которая заменяет собой привычный многим Apache + mod_php. А когда требуется добавить возможность работать с Oracle из PHP, то не подготовленный человек, а точнее привычный к настройке Oracle Client для PHP, работающего как модуль Apache, может столкнуться с непредвиденными проблемами, о решении которых я попробую рассказать.

Итак, у нас CentOS (в принципе на других Linux все будет аналогично) на который уже установлен Nginx, PHP, PHP-FPM и Oarcle Client + модуль php_oci8. На всякий случай, в этом можно убедиться командой:

# php -m | grep oci

Если вывод такой же, как в примере ниже, то модуль установлен:

# php -m | grep oci
oci8

Но при попытке использовать oci_connect(...) получаем вот такую ошибку:

Warning: oci_connect(): OCIEnvNlsCreate() failed. There is something wrong with your system - please check that ORACLE_HOME and LD_LIBRARY_PATH are set and point to the right directories in /var/www/...

Когда все известные бубны с прописыванием ORACLE_HOME и LD_LIBRARY_PATH во все скрипты запуска и прочие перебраны, но все равно не работает, то простое решение кажется просто невозможным, но оно есть!

Читать дальше...

21 Марта 2016 17:09

Промышленная модель разработки средствами GIT

Про работу Linux Git

Итак, у нас для начала уже есть сервер на котором настроен gitolite по адресу git.example.com, на нем расположен репозиторий myrepo в котором есть две основные ветки master и develop.

Общий принцип разработки такой:

  1. При необходимости что-то доработать разработчик создает новую ветку из актуального состояния master
  2. Делает в ней доработку и вливает ветку в develop
  3. Проводится тестирование и если все хорошо, то ветка с доработкой вливается в master

Задача заключается в том, чтоб при изменениях в ветке develop они автоматически переносились в рабочую копию на хост develop.example.com, а изменения сделанные в master - на хост production.example.com.

Читать дальше...

18 Февраля 2016 19:44

Раскрашиваем MC на удаленном сервере

В мемориз Linux

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

MC умеет скины и они у него есть в комплекте, хранятся в

/usr/share/mc/skins

Попробовать скин можно коммандой

mc -S skinname

Скины бывают обычные и высококачественные, для 256 цветов, например мне полюбился xoria256 (на картинке выше), который и захотелось использовать везде. Везде - это везде куда я прихожу по ssh.

Для того, чтоб избавиться от длинной команды можно установить переменную окружения MC_SKIN, чтоб не набирать каждый раз. Ну а раз можно так, то значит можно пробросить эту переменную через ssh.

Читать дальше...

11 Февраля 2016 16:10

Настраиваем сервер gitolite и клиента на Mac OS

Linux Git Mac OS

В качестве возможности провести свободное время, расскажу свой опыт настройки сервера gitolite на Linux машине и организовать работу клиента на Mac OS :)

На старте у нас имеется сервер под управлением CentOS, который будет выступать хостингом репозиториев; и клиент на Mac OS Yosemite, который будет с ним работать.

Подготовительный этап

Для самого начала нам потребуются ssh ключи. На любой машине генерим приватный и публичный ключ командой

ssh-keygen -t rsa

После этого будет создана пара ключей 

~/.ssh/id_rsa.pub
и
~/.ssh/id_rsa

Эти ключи будут использоваться для администратора gitolite, но их так же можно использовать и для себя в качестве клиента, поэтому можно создавать их и на клиентской машине. Далее я буду рассматривать ситуацию когда эти ключи используются как для админа так и для клиента, поэтому приватный ключ должен оказаться на клиентской машине, например в файле ~/.ssh/git, а публичный - на сервере в файле /tmp/git.pub.

Важное замечание, если вы генерите non-openssh public keys, например, при помощи PuTTY gen, то для использования в gitolite публичный ключ придется конвертировать командой

ssh-keygen -i -f /tmp/ssh2/YourName.ppk > /tmp/openssh/YourName.pub

Это типичная проблема при использовании, например, TurtoiseGit на windows, когда для того чтоб он принял ключ он должен быть в формате *.ppk, а на сервере - в фомате openssh.

Читать дальше...

13 Апреля 2014 00:04

Домашний майнинг с водяным охлаждением

Linux Хобби Моддинг Железо

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

Как известно, самый популярный способ майнинга валют основанных на scrypt алгоритмах - это использование обычных топовых видео карт для перебора хэшей. Причем эффективность этого процесса пропорциональна естественно мощности карт и их количеству. Таким образом энтузиасты собирали целые фермы, где на одну материнскую плату приходилось 2-5 видюх и вся эта конструкция занималась круглосуточно вычислениями. Естественно охлаждающие системы видео карт не рассчитаны на то, что карта будет постоянно под 100% нагрузкой, а рядом от нее будут такие же грелки. Поэтому для того чтоб не пожечь карты их приходилось разносить подальше друг от друга, а в идеале еще и обеспечивать приток холодного воздуха для системы охлаждения. В результате получались просто монстры, которые еще и гудели как идущий на взлет самолет.

Естественно уподобляться массам, которые собирают фермы которые занимают место и издают много шума у меня не было ни желания ни возможности, банально не было даже помещения где все это расположить. От этого задача становилась еще интереснее: нужно было создать майнер, который был бы компактным, да еще и не шумел при полной нагрузке, ну или шумел так чтоб его можно было держать в квартире и одновременно там жить.

Выбор видео карт

Началось все естественно с выбора видео карт. Нужно было найти карту с наилучшим соотношением производительность (в количестве хэшей) и энергопотребление. Да именно потребление энергии основная проблема тк при майнинге видео карта потребляет весьма много электричества. Ну и цена тоже играла не последнюю роль.

После долгих поисков, чтения профильных форумов, спецификаций и расчетов был выбран Radeon R9 290, который по соотношению количество мегахэшей на ватт электричества оказался более эффективен, чем его старший и более дорогой товарищ Radeon R9 290X. Невероятно но факт.

Читать дальше...

Фильтр