Блог

Техническая поддержка филиальной сети – достаточно типовая задача для ИТ-специалиста. Часто это были весьма специфичные решения: начиная от использования собраний в Outlook как HelpDesk-системы и заканчивая использованием антивируса в качестве системы мониторинга удаленных хостов. Так или иначе, за некоторое время удается подобрать системы, которые наилучшим образом подходят для решения задач подразделения технической поддержки.

Как правило, в технической поддержке нужны следующие категории систем:

• Система HelpDesk
• Мессенджер
• Система базы знаний
• Система мониторинга удаленных рабочих станций
• Система управления конфигурациями
• Система удаленного управления рабочими станциями
• Система централизованной установки софта и административных действий на рабочих станциях
• Система развертывания релизов (обновления конфигурации)
• Система учета ИТ-оборудования

Часто это неполный перечень информационных систем, которые используются в компаниях. Универсальные решения от вендоров (Microsoft/1C/SAP) достаточно хорошо выполняют одни задачи и абсолютно не проработаны для других. Поэтому со временем я пришел к выводу, что для каждой группы задач нужно подбирать свою систему, которая подходит для них наилучшим образом. Часто подобные узкоспециализированные системы не стоят денег, т.к. являются достаточно простыми Open Source-решениями. Если подходящей системы не существует, бывает проще вложить силы в разработку, чем использовать некоторые половинчатые решения. Далее рассмотрим отдельно системы каждой категории.

Система HelpDesk

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

У меня была возможность протестировать многие решения подобного рода:

• HP OpenView
• ManageEngine
• Mantis
• Redmine
• 1С Итилиум
• 1С ITIL
• OTRS
• JIRA Service Desk

Как правило, мой выбор всегда останавливается на решениях от «1С» – по элементарно простым причинам: вся техподдержка умеет с ними работать (1С-ный интерфейс знаком весьма неплохо) и кастомизация систем ограничена только личными фантазиями (в штате есть 1С-программисты). Наиболее выгодным образом выглядит 1С:ITIL. Данная система является достаточно функциональной, на рынке существует давно, весьма проработана. Исходный код полностью открыт, лицензии нужны только обычные 1С. В части функциональности при этом ничем особо не уступает дорогим продуктам от HP. Кроме всего прочего, содержит в себе модули управления конфигурациями и учета оборудования.

Но в настоящий момент мы используем JIRA Service Desk. Перед 1С ITIL у нее есть ряд преимуществ:

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

Удобный функционал очередей для распределения заявок (у 1С все-таки все в куче – другой принцип).

Для нас нормальный веб-интерфейс оказался критичен – много сотрудников, не знакомых с 1С, работают удаленно. Кроме всего прочего, сама система очень неплоха.

Система базы знаний

Каждая уважающая себя HelpDesk-система имеет внутри себя базу знаний. Использовать базу знаний внутри HelpDesk-системы кажется логичным на первый взгляд. К сожалению, только на первый. Мне не встречалось ни одной удачной реализации базы знаний внутри HelpDesk-системы. Это все-таки должен быть специализированный продукт, решающий подобные задачи. База знаний – это не набор неструктурированных документов Word, описывающих разные процессы, это не папка с инструкциями, это не набор бессвязных ответов на обращения. База знаний – некоторое структурированное хранилище информации, актуальность которого поддерживается и отслеживается, по нему должен быть доступен поиск. Разумеется, идеальная база знаний должна быть в формате Wiki, который уже давно стал стандартом для подобного рода решений. Из Wiki-движков как наиболее функциональные можно выделить следующие:

• MediaWiki
• DokuWiki
• Sharepoint Wiki MediaWiki
• Confluence

естественно, вне конкуренции по технической реализации и набору функциональности, но для корпоративной базы знаний, как оказалось на практике, он подходит не лучшим образом:

• Файлы хранятся в БД, соответственно, конвертировать из Word нет никакой возможности.
• Достаточно долго и проблемно работать с рисунками.
• Трудно использовать внешние ресурсы.
• Внешний вид практически не кастомизируется от стандартного.

Как вы догадались, всех этих недостатков лишен движок DokuWiki , на мой взгляд, конечно. DokuWiki – единственный мне известный движок, который не использует хранение статей непосредственно в БД. Это можно рассматривать как недостаток для современных систем, но, как показала моя практика, для корпоративных баз знаний хранение статей в виде файлов имеет ряд неоспоримых преимуществ:

• Простота конвертации из страниц других форматов. Перед тем как у вас появится Wiki, вы наверняка уже имеете кучу инструкций в формате Word, PDF или аналогичных. Собственно, первичная задача конвертировать их в Wiki; вот тут внедрение базы знаний часто и заканчивается. В случае с DokuWiki вы просто преобразовываете все эти файлы в html, а затем применяете обычный конвертер Wiki-разметки.
• Простота формирования  разделов.  При формировании разделов для переноса групп страниц и их переименования достаточно просто выполнить операции с файлами, что обычно делается быстро и проблем не вызывает.
• Простота настройки.  В отличие от той же MediaWiki, DokuWiki ориентированана внутреннее использование, что позволяет сделать более простые настройки безопасности, более простое и понятное формирование разделов.

Мессенджер

Как это ни странно, мессенджер технической поддержке необходим. Для коммуникации с сотрудниками компании мы чаще всего используем Skype – не корпоративный, т.к. он вызывает много проблем с привязкой к домену, который есть не во всех удаленных узлах. Skype в последнее время стал намного хуже, и настало время подыскивать альтернативы.

Хорошей альтернативой был корпоративный Jabber – открытые протоколы позволяют достаточно удобно с ним взаимодействовать, кроме того, обслуживают мессенджер серверы внутри компании. Но для использования Jabber его нужно централизованно внедрять, в то время как Skype возникает «стихийно».

Существует также мессенджер внутри отдела – общий чат технической поддержки. В современном мире это стало уже «стандартом». Мы для него используем Telegram – пожалуй, наиболее быстрый, удобный, безопасный мессенджер. Для него существует нормальный (быстрый, удобный, не подвисающий, в отличие от того же Viber) десктопный клиент. Возможности передачи больших файлов тоже бывают полезны. Самое главное, почему мы выбрали Telegram, – это возможность разрабатывать диагностические боты. Открытый API для создания ботов сделал данный мессенджер чрезвычайно популярным среди ИТ-команд.

Система удаленного управления рабочими станциями

Набор данных систем достаточно узок. Скорее всего с большей частью из них вы уже сталкивались:

• Ammy Admin
• Radmin
• TeamViewer
• TightVNC

Рисунок 2. Система собственной разработки для развертывания релизов, мониторинга и административных действий на рабочих станциях

Открытый API для создания ботов сделал мессенджер внутри отдела технической поддержки чрезвычайно популярным среди ИТ-команд Администрирование 36 апрель 2017 системный администратор инструменты

Сразу оговорюсь, что основным требованием к этой системе была ее цена и открытость, поэтому TightVNC  была вне конкуренции. TightVNC – бесплатное решение, кроме того, в отличие от AmmyAdmin она имеет достаточно широкий набор функций (передача файлов, служебные комбинации клавиш и т.п.), позволяет создавать ярлыки с автоматическим подключением и работает как служба.

Для нее необходимо иметь внешний IP в удаленных точках; это, конечно, неприятно, но не так критично – практически каждый интернет-провайдер предоставляет данную услугу.

Система мониторинга рабочих станций

Для решения этих задач у себя мы используем систему собственной разработки. К сожалению, перечень задач, которые приходится решать на рабочих станциях, часто слишком широк. Объединение их в рамках Active Directory накладывает некоторые ограничения и не представляется возможным.

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

В нашем случае также важен единый перечень рабочих станций, которые находятся под управлением. Ежедневно появляются новые или закрываются существующие. Данный список актуален в системе 1С:Розница, в которой каждая рабочая станция – это узел обмена. Плотная интеграция с системой развертывания релизов, мониторинга и административных действий – одно из основных требований. Существующие системы, как правило, имеют закрытые протоколы, поэтому для подобной интеграции понадобилось разрабатывать индивидуальные решения.

Еще одной необходимостью была возможность разработки скриптов административных действий на языке C#. Он имеет достаточно мощные средства взаимодействия с ОС, к слову, намного большие, чем у того же PowerShell. Нормальный синтаксис и удобство отладки делают скорость разработки подобных скриптов куда более высокой, чем на традиционных скриптовых языках.

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

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

• резервное копирование,
• динамическое обновление,
• условное статическое обновление (ожидающее подтверждения пользователя),
• безусловное статическое обновления (с завершением работы),
• статическое обновление с перезапуском сервера.

Естественно, в системе есть очередь операций – если она не была выполнена из-за выключенной рабочей станции, она выполнится при ее включении.

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

Мониторинг состояния процессора, памяти, жесткого диска и наличия интернет-соединения происходит просто при периодическом опросе агентов. В других показателях с рабочих станций из нашей практики не было необходимости. Внешний вид системы представлен на рис. 2.

 Система учета ИТ-оборудования

Как было упомянуто выше, 1C ITIL мы не используем в качестве HelpDesk-системы из-за не очень подходящего вебинтерфейса, но есть задачи, для которых системы на платформе 1С просто незаменимы, – это учетные задачи внутри ИТ. В нашем случае это вопросы учета ИТ-оборудования. Для учетных задач 1С подготовлена как нельзя лучше, и 1С ITIL в частности. Решать задачи учета оборудования и конфигурации каждого ПК достаточно легко и удобно. Частично конфигурацию можно получить из AD или использовать тот же Everest. 1С ITIL поддерживает интеграцию и с тем, и с другим, но мы вполне обошлись ручными операциями.

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

Плотная интеграция с системой развертывания релизов, мониторинга и административных действий – одно из основных требований к системе мониторинга.

Установка, настройка и соспровождение ИТ отдела поддержки, современные продукты Jira SD, Jira confluence, bitbacket, jenkins и другие, office@itfb.com.ua или в раздел контакты

Уменя есть файл с именем/etc/passwd, и я хотел бы найти все жесткие ссылки на этот файл в каталоге. Как узнать все жесткие ссылки в каталоге /etc/passwd  и /backups/? Как найти все жесткие ссылки на данный файл с помощью командной строки Linux или Unix?

Вы можете использовать команду find в Linux, Apple MacOS, FreeBSD и в других операционных системах, чтобы найти все жесткие ссылки.

 Как найти все жесткие ссылки на данный файл

Жесткая ссылка – это не что иное, как конкретное местоположение физических данных. Вы задаете разные имена, относящиеся к одному и тому же файлу. Файл относится к inode, что и имя. Жесткие ссылки на файл foo можно создать следующим образом:

$ ln foo bar
$ ln foo dir2/foobar

В приведенном выше примере bar и foobar становятся другим именем файла foo. Синтаксис следующий, чтобы найти все жесткие ссылки для файла foo в текущем каталоге:

find/dir/to/search/-samefile/path/to/file/name
## To find out all hard links to foo, use this command:
find/-samefile foo
find/-xdev -samefile foo

Примеры

Если файл с именем /etc/passswd и вам нужно получить все жесткие ссылки, которые существуют в каталоге/backups/, запустите:

$ find/backups/ -samefile/etc/passwd

Пример результата:

/backups/hourly.0/etc/passwd
/backups/hourly.4/etc/passwd
/backups/hourly.3/etc/passwd
/backups/daily.0/etc/passwd
/backups/hourly.1/etc/passwd
/backups/hourly.2/etc/passwd

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

$ find/backups/ -xdev -samefile/etc/passwd

НАЙТИ И УДАЛИТЬ ВСЕ ЖЕСТКИЕ ССЫЛКИ НА ФАЙЛ С ИМЕНЕМ FOO в /TMP/

Введите следующую команду:

$ find /tmp/ -xdev -samefile foo -print0 | xargs -I {} -0 rm -v {}

Пример результата:

 Удалено '/tmp/dir2/foobar'
 Удалено '/tmp/foo'
 Удалено '/tmp/bar'

Справка, параметр -samefile не поддерживается командой find

Определить номер inode файла, введите:

$ ls -li fileNameHere
$ ls -li /tmp/demo.txt

Пример резульатат:

  4065089 -rw-r-r-- 3 root root 8 февраля 26 02:19/tmp/demo.txt

Первый столбец в приведенном выше примере отображает индекс inode # 4065089. Теперь альтернативный синтаксис выглядит следующим образом, чтобы найти все жесткие ссылки для файла с именем /tmp/demo.txt, используя inode # 4065089:

$ find /tmp/-inum 4065089
$ find /tmp/-xdev -inum 4065089

Пример  результата:

/tmp/demo.txt
/tmp/dir2/file2.txt
/tmp/file1.txt

Чтобы найти и удалить все жесткие ссылки на файл по номеру inode # 4065089, запустите:

$ find /tmp/-xdev -inum 4065089 | xargs rm -v
$ find /tmp/-xdev -inum 4065089 -print0 | xargs -I {} -0 rm -v {}

Вот мой пример:

Круглосуточная поддержка Linux/Unix серверов, office@itfb.com.ua

В предыдущей статье мы рассказывали о том, как настроить Сервис Деск систему на базе Jira сделав минимум изменений в конфигурации из коробки. В этой публикации речь будет идти о разработке, заточенной под рабочие процессы компании.

Итак, принцип работы: Первая линия принимает обращения пользователей по нескольким каналам связи: почта, мессенджеры (Skype, Telegram, пр.), звонки, сообщения системы мониторинга и других систем. Проблемы, для которых решение известно, и его возможно выполнить за 30 минут, закрываются непосредственно специалистами первой линии. Остальные – передаются далее по цепочке более компетентным или свободным администраторам. Ключевые моменты, на которые было обращено при разработке решения:

• Задача не должна потеряться
• Задача должна быть обработана в сроки, оговоренные в SLA
• Задача не должна быть отставлена без внимания в процессе решения.

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

Таким образом, в нашем решении появилось 2 типа задач: принятые вручную и принятые автоматически. Бизнес процессы для них практически одинаковые. Поэтому логику работы мы будем рассматривать на Workflow для автоматически принятых заявок.   Выглядит он следующим образом:

Созданная задача имеет статус Waiting for support, и может находиться в таком состоянии до 5ти минут. За это время задачу должен назначить на себя кто-то  из специалистов Сервис Деск. В противном случае задача подсвечивается красным, а система начинает оповещать о том, что есть необработанные задачи.

Назначенная задача переходит в статус Open. С этого статуса также начинается обработка задачи созданной в ручном режиме. У обоих бизнес процессов есть два статуса приостановки работы: по причине ожидания пользователя и по иным причинам, связанным с внутренними вопросами команды Service Desk. Также есть четыре статуса, при которых работа над задачей завершена:

• Done – заявка выполнена.
• Closed – заявка закрыта без выполнения.
• Escalated и Autoescalated – заявка передана на выполнение за пределы команды Сервис Деск.

На выполнение задачи у специалиста технической поддержки есть 30 минут, без учета времени в статусах ожидания. Если за это время задача не решена, она автоматически переходит в статус Autoescalated.

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

Собственно – все. Все автоматические действие выполняются при изменении статуса задачи с помощью post-функций. Для создания новых задач используется Run CLI Actions in JIRA add-on, для изменения значений полей используется JIRA Misc Workflow Extensions add-on (ссылка на статью), для формирования специфических проверок Adaptavist ScriptRunner for JIRA add-on. О некоторых из них мы писали ранее, некоторые стоят того, чтобы посвятить им отдельную статью.

«Зачем же использовать Jira Service Desk, если все делается с  помощью post-функций?» – резонно спросите Вы. Сервис Деск используется для:

• организации автоматизированной проверки SLA;
• организации реакции на превышение этих значений;
• организации очередей и отчетности;
• группировки наборов пользовательских (клиентских) записей в Организации.
• В будущем планируется использование портала для создания автоматически решаемых задач.

За время эксплуатации системы был выявлен ряд неудобств. Например:

• Для того чтобы избежать возможного превышения SLA, сотрудники решают задачи, а потом создают их в Jira.
• Задача, которая ушла на вторую линию технической поддержки, не имеет с первой линией обратной связи, кроме ссылки, соответственно при анализе закрытых задач первой линии невозможно понять, решена ли проблема.
• Виден ряд задач, которые могли бы быть решены в автоматическом режиме, при наличии необходимой информации в нужных полях задачи.

Для всех этих проблем, уже найдены решения и сейчас они находятся на этапе внедрения и тестовой эксплуатации. Мы расскажем Вам о них в будущих публикациях.

Если у Вас есть вопросы по организации систем Сервис Деск на базе продуктов Attlassian – обращайтесь. Наш опыт может помочь Вам, office@itfb.com.ua

В той статье мы продемонстрируем решение для установки нескольких версий Phalcon и PHP и запустим их на одном веб-сервере. Здесь будут использоваться PHP 5.5.x и 5.6.x, но вы можете заменить их другими версиями. Можно использовать PHP-FPM, но мы рекомендуем использовать Nginx. В этом руководстве используется среда Fedora OS – система Linux, но инструкции практически идентичны для любой другой ОС * nix.

Предисловие

В этом руководстве рассматривается установка PHP 5.5.x с Phalcon 1.3.x и PHP 5.6.x с Phalcon 2.0.0. Мы также установим дополнительные PHP-расширения, такие как APC, memcache, memcached и ioncube.

Установка Nginx

Nginx – это доступный пакет в операционной системе Fedora, который мы можем установить следующим образом:

sudo yum install nginx

Затем мы создаем системные ссылки для запуска Nginx и запускаем его

sudo chkconfig nginx on sudo service nginx start

Сборка PHP

Прежде чем начинать установку PHP, нам необходимо установить зависимости для создания PHP5:

• Gcc или другой набор компиляторов.
• Libc-dev, предоставляет стандартную библиотеку C, включая заголовки.
• Make,  инструмент использует управления сборкой, используемый PHP.
• Autoconf (2.59 или выше) для генерации скрипта configure.
• Automake (1.4 или выше), генерирует файлы Makefile.in.
• Libtool, помогает нам управлять общими библиотеками.
• Bison (2.4 или выше), для генерации парсера PHP.
• (Опционально) re2c, который используется для генерации лексера PHP. Поскольку репозиторий git уже содержит сгенерированный лексер, вам понадобится  re2c только если вы хотите внести в него изменения.

На Centos / Fedora вы можете установить все это с помощью следующей команды:

sudo yum install gcc libxml2-devel libXpm-devel gmp-devel libicu-devel t1lib-devel aspell-devel openssl-devel bzip2-devel libcurl-devel libjpeg-devel libvpx-devel libpng-devel freetype-devel readline-devel libtidy-devel libxslt-devel libmcrypt-devel pcre-devel curl-devel mysql-devel ncurses-devel gettext-devel net-snmp-devel libevent-devel libtool-ltdl-devel libc-client-devel postgresql-devel bison gcc make

Далее нам нужно получить исходный код. Существует два способа сделать это: вы можете загрузить архив со страницы загрузки PHP или клонировать git-репозиторий из Github .

Мы рекомендуем проверить исходный код в git, поскольку он предоставляет вам простой способ поддерживать актуальность вашей установки и пробовать ваш код с различными версиями. Git checkout также требуется, если вы хотите отправлять исправления или запрашивать запросы для PHP.

Чтобы клонировать репозиторий, выполните в терминале следующие команды:

sudo mkdir /opt/source && cd /opt/source
  git clone git@github.com:php/php-src.git && cd php-src

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

  PHP 5.3:  git checkout PHP-5.3
  PHP 5.4:  git checkout PHP-5.4
  PHP 5.6:  git checkout PHP-5.6
  PHP HEAD: git checkout master

Прежде чем перейти к отдельным этапам сборки, мы должны выполнить некоторые команды для «по умолчанию» сборки PHP. Это необходимо только для сборки из git.

sudo ./buildconf

./buildconf создает сценарий конфигурации. Это займет несколько минут.

На мой взгляд, лучше всего хранить весь веб-сервер в одном каталоге, поэтому я использую /opt здесь. Откройте терминал и введите следующую команду.

sudo mkdir -p /opt/php-5.6 
sudo mkdir -p /opt/php-5.5

После ./configure сценария ./configure с помощью описанного выше шага вы можете использовать его для настройки сборки PHP. Вы можете просмотреть все поддерживаемые параметры, используя -help:

./configure --help

В приведенной выше команде будут перечислены различные общие параметры, которые поддерживаются всеми скриптами конфигурации на основе autoconf. Один из них уже упоминается -prefix = DIR, который меняет каталог установки, используемый командой make install . Другой полезной опцией является -C, которая кэширует результат различных тестов в файле config.cache и ускоряет ./configure вызовы ./configure . Использование этой опции имеет смысл только после того, как у вас уже есть рабочая сборка и вы хотите быстро переключаться между различными конфигурациями.

Вот несколько полезных параметров:

[...]

  Usage: ./configure [OPTION]... [VAR=VALUE]...

  To assign environment variables (e.g., CC, CFLAGS...), specify them as
  VAR=VALUE.  See below for descriptions of some of the useful variables.

  Defaults for the options are specified in brackets.

  Configuration:
    -h, --help              display this help and exit
        --help=short        display options specific to this package
        --help=recursive    display the short help of all the included packages
    -V, --version           display version information and exit
    -q, --quiet, --silent   do not print `checking ...' messages
        --cache-file=FILE   cache test results in FILE [disabled]
    -C, --config-cache      alias for `--cache-file=config.cache'
    -n, --no-create         do not create output files
        --srcdir=DIR        find the sources in DIR [configure dir or `..']

  Installation directories:
    --prefix=PREFIX         install architecture-independent files in PREFIX
                            [/usr/local]
    --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
                            [PREFIX]

  By default, `make install' will install all the files in
  `/usr/local/bin', `/usr/local/lib' etc.  You can specify
  an installation prefix other than `/usr/local' using `--prefix',
  for instance `--prefix=$HOME'.

  For better control, use the options below.

  Fine tuning of the installation directories:
    --bindir=DIR            user executables [EPREFIX/bin]
    --sbindir=DIR           system admin executables [EPREFIX/sbin]
    --libexecdir=DIR        program executables [EPREFIX/libexec]
    --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
    --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
    --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
    --libdir=DIR            object code libraries [EPREFIX/lib]
    --includedir=DIR        C header files [PREFIX/include]
    --oldincludedir=DIR     C header files for non-gcc [/usr/include]
    --datarootdir=DIR       read-only arch.-independent data root [PREFIX/share]
    --datadir=DIR           read-only architecture-independent data [DATAROOTDIR]
    --infodir=DIR           info documentation [DATAROOTDIR/info]
    --localedir=DIR         locale-dependent data [DATAROOTDIR/locale]
    --mandir=DIR            man documentation [DATAROOTDIR/man]
    --docdir=DIR            documentation root [DATAROOTDIR/doc/PACKAGE]
    --htmldir=DIR           html documentation [DOCDIR]
    --dvidir=DIR            dvi documentation [DOCDIR]
    --pdfdir=DIR            pdf documentation [DOCDIR]
    --psdir=DIR             ps documentation [DOCDIR]
 
  [...]

После завершения подготовки мы устанавливаем версию 5.6 PHP. Выполните следующее:

./configure \
--prefix=/opt/php-5.6 \
--with-pdo-pgsql \
--with-zlib-dir \
--with-freetype-dir \
--enable-mbstring \
--with-libxml-dir=/usr \
--enable-soap \
--enable-calendar \
--with-curl \
--with-mcrypt \
--with-zlib \
--with-gd \
--with-pgsql \
--disable-rpath \
--enable-inline-optimization \
--with-bz2 \
--with-zlib \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-pcntl \
--enable-mbregex \
--with-mhash \
--enable-zip \
--with-pcre-regex \
--with-mysql \
--with-pdo-mysql \
--with-mysqli \
--with-png-dir=/usr \
--enable-gd-native-ttf \
--with-openssl \
--with-fpm-user=nginx \
--with-fpm-group=nginx \
--with-libdir=lib64 \
--enable-ftp \
--with-imap \
--with-imap-ssl \
--with-kerberos \
--with-gettext \
--with-gd \
--with-jpeg-dir=/usr/lib/
--enable-fpm

Последний переключатель (-enable-fpm) позволяет этой версии PHP работать с PHP-FPM. Если вы хотите использовать эту версию PHP-FPM с Apache, --with-fpm-user=apache и --with-fpm-group=apache . С другой стороны, если вы хотите использовать эту версию PHP-FPM с nginx, --with-fpm-user=nginx и --with-fpm-group=nginx .

Успешное сообщение должно быть в  терминале:

[...]

creating libtool
appending configuration tag "CXX" to libtool

Generating files
configure: creating ./config.status
creating main/internal_functions.c
creating main/internal_functions_cli.c
+--------------------------------------------------------------------+
| License:                                                           |
| This software is subject to the PHP License, available in this     |
| distribution in the file LICENSE.  By continuing this installation |
| process, you are bound by the terms of this license agreement.     |
| If you do not agree with the terms of this license, you must abort |
| the installation process at this point.                            |
+--------------------------------------------------------------------+

Thank you for using PHP.

config.status: creating php5.spec
config.status: creating main/build-defs.h
config.status: creating scripts/phpize
config.status: creating scripts/man1/phpize.1
config.status: creating scripts/php-config
config.status: creating scripts/man1/php-config.1
config.status: creating sapi/cli/php.1
config.status: creating sapi/fpm/php-fpm.conf
config.status: creating sapi/fpm/init.d.php-fpm
config.status: creating sapi/fpm/php-fpm.service
config.status: creating sapi/fpm/php-fpm.8
config.status: creating sapi/fpm/status.html
config.status: creating sapi/cgi/php-cgi.1
config.status: creating ext/phar/phar.1
config.status: creating ext/phar/phar.phar.1
config.status: creating main/php_config.h
config.status: executing default commands

Теперь вы можете использовать make для выполнения фактической компиляции:

make

Основным результатом этой операции будут двоичные файлы PHP для включенных SAPI (по умолчанию sapi/cli/php и sapi/cgi/php-cgi), а также общие расширения в каталоге modules/.

Теперь вы можете запустить «make install» для установки PHP в /usr/local (по умолчанию) или в других каталогах, используя конфигурацию --prefix . В этом случае это /opt/php-5.6

sudo make install

Обратите внимание, что make install не будет создавать INI-файл.

/opt/php-5.6/bin/php --ini
Configuration File (php.ini) Path: /opt/php-5.6/lib
Loaded Configuration File:         (none)
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

Скопируйте php.ini и php-fpm.conf в правильный каталог:

sudo cp /opt/source/php-src/php-fpm.conf.default /opt/php-5.6/etc/php-fpm.conf
sudo cp /opt/source/php-src/php.ini-production /opt/php-5.6/lib/php.ini

Мы проверяем версию php еще раз.

/opt/php-5.6/bin/php --ini
  Configuration File (php.ini) Path: /opt/php-5.6/lib
  Loaded Configuration File:         /opt/php-5.6/lib/php.ini
  Scan for additional .ini files in: (none)
  Additional .ini files parsed:      (none)

  ### Checking php
  /opt/php-5.6/bin/php --version
  PHP 5.6.2-dev (cli) (built: Oct  2 2014 17:20:23) 
  Copyright (c) 1997-2014 The PHP Group
  Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies

Откройте /opt/php-5.6/etc/php-fpm.conf и /opt/php-5.6/etc/php-fpm.conf . Вы должны переключиться на неиспользуемый порт (например, 9001, порт 9000 может использоваться Fedora)

vi /opt/php-5.6/etc/php-fpm.conf

[...]
  pid = run/php-fpm.pid
  [...]
  user = nginx
  group = nginx
  [...]
  listen = 127.0.0.1:9001
  [...]
  #include=/opt/php-5.6/etc/pool.d/*.conf

Настройка сценария Init

Вероятно, вы захотите создать сценарий инициализации для вашего нового php-fpm. К счастью, PHP 5.3+ уже предоставляет его вам, просто скопируйте сценарий init в свой каталог и измените разрешения:

sudo cp /opt/source/php-src/sapi/fpm/init.d.php-fpm /etc/init.d/php5.6-fpm
sudo chmod 755 /etc/init.d/php5.6-fpm

Ваш скрипт инициализации готов. Теперь вы можете запускать, останавливать и перезагружать php-fpm:

sudo /etc/init.d/php5.6-fpm start
  sudo /etc/init.d/php5.6-fpm stop
  sudo /etc/init.d/php5.6-fpm reload

Сборка второго PHP (5.5.x)

Открываем терминал и вводим следующую команду.

git checkout PHP-5.5
sudo ./buildconf 
./configure \
--prefix=/opt/php-5.5 \
--with-pdo-pgsql \
--with-zlib-dir \
--with-freetype-dir \
--enable-mbstring \
--with-libxml-dir=/usr \
--enable-soap \
--enable-calendar \
--with-curl \
--with-mcrypt \
--with-zlib \
--with-gd \
--with-pgsql \
--disable-rpath \
--enable-inline-optimization \
--with-bz2 \
--with-zlib \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-pcntl \
--enable-mbregex \
--with-mhash \
--enable-zip \
--with-pcre-regex \
--with-mysql \
--with-pdo-mysql \
--with-mysqli \
--with-png-dir=/usr \
--enable-gd-native-ttf \
--with-openssl \
--with-fpm-user=nginx \
--with-fpm-group=nginx \
--with-libdir=lib64 \
--enable-ftp \
--with-imap \
--with-imap-ssl \
--with-kerberos \
--with-gettext \
--with-gd \
--with-jpeg-dir=/usr/lib/ \
--enable-fpm

make && sudo make install

Сборка расширений PHP Phalcon

Чтобы установить несколько версий Phalcon, включая Phalcon 2.0, нам нужно установить Zephir

git clone https://github.com/json-c/json-c.git
  cd json-c
  sh autogen.sh
  ./configure
  make && sudo make install
   
  git clone https://github.com/phalcon/zephir
  cd zephir
  sudo ./install -c

Существует множество способов установки расширений PHP. Мы будем использовать phpize.

Phpize играет ту же роль, что и скрипт ./buildconf для PHP: во-первых, он импортирует систему сборки PHP в ваше расширение путем копирования файлов из $PREFIX/lib/php/build . Среди этих файлов: acinclude.m4 (макросы PHP M4), phpize.m4 (который будет переименован в файл configure.in в вашем расширении и содержит основные инструкции по сборке) и run-tests.php .

Затем phpize вызовет autoconf для создания файла ./configure , который можно использовать для настройки сборки расширения. Например, для установки memcached вы должны добавить --enable-memcache .

Запомните! Вы должны указать параметр --with-php-config при создании расширений (если у вас не используется ​​только одна глобальная установка PHP). В противном случае ./configure не сможет правильно определить версию PHP и флаги. Кроме того, скрипт php-config также гарантирует, что команда «make install» переместит сгенерированный *.so файл в нужный каталог расширения.

Создание первого PHP Phalcon (2.0)

git clone http://github.com/phalcon/cphalcon
  cd cphalcon && git checkout 2.0.0
  zephir compile
  cd ext && /opt/php-5.6/bin/phpize
  ./configure --with-php-config=/opt/php-5.6/bin/php-config
  make && sudo make install
  Installing shared extensions:     /opt/php-5.6/lib/php/extensions/no-debug-non-zts-20131226/

Проверьте, успешна ли сборка.

ls /opt/php-5.6/lib/php/extensions/no-debug-non-zts-20131226/

После установки расширения. Вам все равно нужно активировать его, включив его в файл php.ini.

sudo su echo "extension=phalcon.so" >> /opt/php-5.6/lib/php.ini exit

Сборка второго PHP Phalcon (1.3.x)

git clone http://github.com/phalcon/cphalcon
  cd cphalcon && git checkout master
  cd ext && /opt/php-5.5/bin/phpize
  ./configure --with-php-config=/opt/php-5.5/bin/php-config
  make && sudo make install
  Installing shared extensions:     /opt/php-5.5/lib/php/extensions/no-debug-non-zts-20121212/

Мы снова проверяем, чтобы установка прошла успешно.

ls /opt/php-5.6/lib/php/extensions/no-debug-non-zts-20131226/
  sudo su
  echo "extension=phalcon.so" >> /opt/php-5.5/lib/php.ini
  exit

Настройка Nginx

sudo vi /etc/nginx/nginx.conf

Следующая конфигурация создаст два сервера: phalcon-prd.localhost работает на PHP 5.5.x и phalcon-dev.localhost работает с PHP 5.6.x. Это пример, вы можете настроить для своего сервера

[...]
http {
  include       mime.types;
  default_type  application/octet-stream;
  sendfile        on;
  keepalive_timeout  65;
  #gzip  on;
  include /etc/nginx/conf.d/*.conf;

  index index.php index.html index.htm;

  #Prodution environment Phalcon
  server {
    listen       80;
    server_name  phalcon-prd.localhost;

    root   /usr/share/nginx/html/phalcon-prd;

    location / {
      index  index.php;
    }

    location ~ \.php$ {
      fastcgi_pass   127.0.0.1:9001;
      fastcgi_index  index.php;
      fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
      include        fastcgi_params;
    }
  }
  #Development environment Phalcon
  server {
    listen       80;
    server_name  phalcon-dev.localhost;

    root   /usr/share/nginx/html/phalcon-prd;

    location / {
      index  index.php;
    }

    location ~ \.php$ {
      fastcgi_pass   127.0.0.1:9002;
      fastcgi_index  index.php;
      fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
      include        fastcgi_params;
    }
  }
}
[...]

Настроить файл локальных хостов на своей машине для тестирования

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

sudo vi /etc/hosts

Новый файл хоста будет выглядеть так.

[...]
127.0.0 localhost phalcon-dev.localhost phalcon-prd.localhost
::1   localhost6.localdomain6 localhost6
[...]

Это нужно для перехвата всех запросов phalcon-dev.localhost и phalcon-prd.localhost а затем phalcon-prd.localhost передает их на ваш сервер.

Тестирование

Для тестирования мы создаем новый файл с именем test.php и помещаем его в папку, соответствующую указанной выше конфигурации Nginx. В каждый файл добавляется следующая команда.

<?php phpinfo(); ?>

Теперь, запустив файл test.php на каждом сервере, мы видим phalcon 1.3.x phpinfo() по адресу http: //phancon-prd.localhost/test.php, а в http: //phancon-dev.localhost/test. Php должен быть phpinfo() Phalcon 2.0.x.

В заключение

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

Нужна установка нескольких версий php на сервер, обращайтесь office@itfb.com.ua

Угроза ИТ безопасности

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

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

Основные особенности современных угрозы информационной безопасности:

1. Целенаправленные атаки

Создание вредоносного программного обеспечения сегодня – это вид организованной преступности, главная цель которой получение значительный финансовой прибыли. Осталось в прошлом время, когда вирусы и другое зловредное ПО писалось хакерами одиночками или группами таких лиц исключительно ради самоутверждения, забавы или приобретения авторитета в своей неформальной среде. Заражение вирусами ранее не носило массовый и одномоментный характер, который мы можем видеть сегодня (как это было, например, с атакой WannaCry). Распространение вредоносного кода по сети Интернет или другим каналам ранее чаще всего происходило хаотично. На сегодня ситуация в корне изменилась. Основная часть хакерских атак имеют четкую и конкретную цель. Если речь идет об отдельном предприятии или отрасли, то атаке предшествует детальный сбор информации о потенциальной жертве, изучение наиболее слабых и уязвимых мест для проникновения вредоносного кода.

2. Использование человеческого фактора и методов социальной инженерии

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

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

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

3. Атаки растянуты во времени

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

4. Угрозы техногенного характера

Атака с помощью вируса BlackEnergy на ряд объектов в Украине в 2015 г. показала способность хакеров влиять на работу не только ИТ-систем, но и на функционирование промышленных объектов, что говорит о еще более угрожающих возможных последствиях от деятельности хакеров. Тогда в декабре 2015 г. в результате атаки на «Прикарпатьеоблэнерго» было отключено около 30 подстанций и в результате около 230 тыс. жителей Ивано-Франковской области оставались без света около 6 часов.

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

Обеспечение информационной безопасности предприятия, большой опыт внедрения (на малых предприятий, крупных организациях и холдинге численностью сотрудников до 7 тыс. ), office@itfb.com.ua

Я новый пользователь Arch Linux. Как найти репозиторий для устанавливаемых пакетов под Arch Linux с помощью опции командной строки?

Вы можете использовать команду pacman или pkgfile для поиска пакета в Arch Linux с использованием оболочки bash.

Как найти пакет с помощью pacman?

Синтаксис:

pacman -Ss {pkgNameHere} 
pacman -Ss {keyWordHere}

Например, для поиска nmap введите команду pacman:

$ pacman -Ss nmap

ИЛИ

$ pacman -Ss auditing

Как найти пакет с помощью pkgfile?

Команда pkgfile представляет собой не что иное, как исследователь метаданных pacman .files. Сначала установите pkgfile, введите:

$ sudo pacman -S pkgfile

Пример результата:

Введите следующую команду для обновления индекса:

$ sudo pkgfile --update

Простой поиск

Введите команду:

$ pkgfile nginx 
$ pkgfile php 
$ pkgfile nmap

Как просмотреть файлы неустановленного пакета?

Синтаксис

$ pkgfile -l packageName 
$ pkgfile -l nmap 
$ pkgfile -l bash

Чтобы просмотреть список файлов, локального пакета, используйте:

$ pacman -Ql bash

Как выполнить сопоставление с регулярными выражениями?

Синтаксис:

$ pkgfile -r regex 
$ pkgfile -r php* 
$ pkgfile -r nginx*

Просмотреть все другие параметры

Синтаксис:

$ pkgfile -h

для CentOS / Red Hat Enterprise Linux

Используйте следующую команду yum

$ yum search pkgName 
$ yum search php

для Fedora Linux

Используйте следующую команду dnf

$ dnf search pkgName 
$ dnf search php

для Debian / Ubuntu Linux

Используйте следующую команду apt

$ apt search pkgName 
$ apt search php

для Suse / OpenSuse Linux

Используйте следующую команду zypper

$ zypper search pkgName 
$ zypper search php

для Alpin Linux

Используйте следующую команду apk

$ apk search pkgName 
$ apk search php

для Gentoo Linux

Используйте следующую команду emerge

$ emerge -S pkgName 
$ emerge -S pkgName

Установка, настройка и обслуживание серверов Linux/Unix ОС, office@itfb.com.ua

Vtop – графический монитор активности командной строки, написанный в Node.js. Как установить vtop на моем Linux-сервере?

На странице проекта:

 

Средства командной строки, такие как «top», затрудняют просмотр использования процессора в многопроцессных приложениях (например, Apache и Chrome), с течением времени и использовании памяти. Вот почему мы создали vtop. Vtop – это бесплатный монитор активности с открытым исходным кодом для командной строки. Он написан на node.js и может быть легко расширен

Установка

Сначала установите Node.js, если он не установлен в вашей системе. Затем введите следующую команду для установки vtop:

$ sudo npm install -g vtop

Пример результата:

Как мне его использовать?

Введите команду:

$ vtop

Пример результата:

Вы можете настроить тему vtop:

$ vtop -t wizard

Возможные варианты темы: кислота, бекка, варево, темный, монокай, параллакс, сетi и волшебник:

$ vtop -t parallax

Пример результата: