На выбор в репозитории предлагается 4 варианта возможной конфигурации:
- pure-ftpd
- FTP-сервер, с аутентификацией через системных пользователей,
- pure-ftpd-ldap
- FTP-сервер, с аутентификацией через пользователей LDAP,
- pure-ftpd-mysql
- FTP-сервер, с аутентификацией через пользователей хранимых в СУБД MySQL,
- pure-ftpd-postgresql
- FTP-сервер, с аутентификацией через пользователей хранимых в СУБД PostgreSQL.
Небольшие пояснения:
- символ #
(решётка) - означает выполнение команды от root (суперпользователя),
- cat /path/to/some.file
- означает что ниже приведено полное содержимое файла some.file
, расположенного в директории /path/to
,
- echo no > /path/to/some.file
- означает, что в some.file
будет вставлен текст no
, с заменой содержимого. Если файл не существует, он будет создан.
Я выбрал вариант с поддержкой MySQL:
# apt-get install pure-ftpd-common pure-ftpd-mysql
Одной из особеннойстей PureFTPd является то, что каждый параметр конфигурации хранится в отдельном файле. И каждый файл имеет имя параметра, а в самом файле хранятся значения этих параметров. Файлы эти расположены в директории:
/etc/pure-ftpd/conf
Рассмотрим наиболее интересные файлы конфигурации предоставленные нам мейнтейнерами по умолчанию.
Указан файл для логов трансфера, в формате Apache:
# cat /etc/pure-ftpd/conf/AltLog
clf:/var/log/pure-ftpd/transfer.log
Указан файл конфигурации для MySQL:
# cat /etc/pure-ftpd/conf/MySQLConfigFile
/etc/pure-ftpd/db/mysql.conf
Анонимным пользователям доступ запрещен:
# cat /etc/pure-ftpd/conf/NoAnonymous
yes
Теперь необходимо дополнить конфигурацию. Для начала запретим UNIX-аутентификацию:
# echo no > /etc/pure-ftpd/conf/UnixAuthentication
Затем запретим PAM-аутентификацию:
# echo no > /etc/pure-ftpd/conf/PAMAuthentication
Ограничим пользоватей их домашним каталогом:
# echo "yes" > /etc/pure-ftpd/conf/ChrootEveryone
Укажем диапазон портов для пассивных соединений:
# echo "40110 40210" > /etc/pure-ftpd/conf/PassivePortRange
Не забудьте потом открыть необходимые порты в брандмауэре.
По ссылке доступна таблица со всеми возможными параметрами которые я нашел.
Есть два веб-интерфейса, которые я нашел. Это PureFTPd WebUI и User Manager. Для себя я выбрал PureFTPd WebUI. Ну-с, приступим к установке.
Переходим в директорию файлов веб-сервера:
1
|
|
Где sitename
- директория веб-сервера с уже настроенным сайтом.
Скачаем файлы веб-интерфейса с гитхаба:
1
|
|
Переходим в скачаный каталог pure-ftpd-webui
:
1
|
|
В одном из файлов я нашел ошибку в функции create_table_settings()
. Неверно указано значение параметра pureftpd_init_script_path
и отсутствует параметр pureftpwho_path
. Надо заменить строку:
1
|
|
На
1 2 |
|
Для нормального доступа у вас уже должен быть настроен веб-сервер. После того как откроете страницу http://sitename/pure-ftpd-webui
, вам будет доступна страница настройки:
Где sitename
- доменное имя сервера или его IP-адрес.
После того как вы нажмете кнопку Install вы попадете на страницу настройки подключения к СУБД MySQL:
На следующем шаге, вам предложат указать параметры пользователя для подключения к веб-интерфейсу:
После завершения настройки, вам будет доступен интерфейс для управления PureFTPd:
]]>Искал альтернативу pgAdmin3 поддерживающую работу через веб-интерфейс и наткнулся phpPgAdmin. На мой взгляд очень удобный иструмент для работы с PostgreSQL. Хотя и отстает в функционале от pgAdmin3, но мне вполне хватает. Так же для меня важно, что phpPgAdmin достаточно установить и настроить один раз. В качестве веб-сервера используется Apache 2.4.
Процесс установки phpPgAdmin, для Debian и других ОС основанных на нем будет выглядеть так:
1
|
|
В случае CentOS должен быть установлен репозиторий EPEL, а команда на установку будет выглядеть так:
1
|
|
И всё бы было замечательно, но конфигурация в пакете для Apache 2.2, а у меня Apache 2.4. Потому надо подправить конфигурационный файл.
Конфигурационный файл в Debian:
1
|
|
Конфигурационный файл в CentOS:
1
|
|
К следующему виду:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
|
В параметре Require
мы задаем правила доступа к phpPgAdmin. В вышеуказанном примере, доступ разрешается по маске 192.168.1
, остальные доступа не имеют. Потому, если вы планируете подключатся например из дома, то закомментируйте строку Require ip 192.168.1
и раскомментируйте строку Require all granted
, это позволит открывать страницу phpPgAdmin с любого IP-адреса. Но, если вы разрешили подключение из-за пределов вашей локальной сети, стоит включить обязательную проверку пароля в PostgreSQL.
Ну и напоследок следует отключить дополнительную защиту при авторизации. Для этого нужно в конфигурационном файле phpPgAdmin в параметре $conf['extra_login_security']
выставить значение false
.
Конфигурационный файл phpPgAdmin в Debian:
1
|
|
Конфигурационный файл phpPgAdmin в CentOS:
1
|
|
Если вы настроили все правильно, то по IP-адресу или доменному имени (если вы настроили его) сервера вам будет доступен веб-интерфейс phpPgAdmin:
На главной странице, вы можете выбрать подходящий язык интерфейса и тему оформления.
ПРИМЕЧАНИЕ! Недавно вышел pgAdmin4, в котором реализовали поддержку веб-интерфейса. Постараюсь на
]]>По просьбе знакомого выкладываю инструкцию по установке и настройке Octopress. Octopress - это простой и удобный генератор статичных сайтов. Он поддерживает выгрузку на GitHub, Bitbucket, Heroku или на ваш сервер с помощью Rsync.
В документации на официальном сайте указано, что для корректной работы Octopress требуется Ruby версии 1.9.3. Но у абсолютного большинства, в репозиториях предлагается версия от 2.1 и выше. В той же документации для того, чтобы установить версию 1.9.3 предлагается использовать rbenv или RVM. Для себя я выбрал RVM (Ruby Version Manager). На его примере мы и рассмотрим установку Octopress.
Для начала установим в систему необходимые пакеты:
1
|
|
ПРИМЕЧАНИЕ! Для наглядности, перед каждой командой будет указан определенный символ, если это #
- значит команда выполняется от имени суперпользователя root, если символ $
- то команда выполняется от имени текущего пользователя.
После чего установим RVM:
1
|
|
Подскажем системе, где искать RVM:
1
|
|
Чтобы в дальнейшем каждый раз не указывать путь до каталога с RVM, добавим путь до него в .bashrc:
1
|
|
Установим необходимую версию Ruby:
1
|
|
Перезапускаем RVM, и выбираем версию 1.9.3. С помощью ключа --default
мы указываем, что будем использовать эту версию по умолчанию:
1 2 3 4 |
|
Смотрим какая версия Ruby используется в данный момент:
1 2 |
|
Отлично! Нужная версия Ruby установна и готова к использованию. Можно приступить к установке Octopress. Скачиваем с GitHub необходимые файлы:
ПРИМЕЧАНИЕ! Установщик может в процессе установки может затребовать пароль, для того чтобы установить в систему необходимые зависимости.
1 2 |
|
Установим gem с названием bundler:
1
|
|
Вышеупомянутый gem позволит нам установить другие gem'ы, указанные в файле Gemfile. Запустим команду установки:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
|
Выхлоп сокращен.
Установим стандартную тему:
1
|
|
Если вас не устраивает стандартная тема, то вы можете выбрать тему по вкусу здесь. Процесс установки альтернативной темы несложен. Переходим в каталог Octopress:
1
|
|
Скачиваем нужную тему:
1
|
|
Где GIT_URL
- имя репозитория темы, а THEME_NAME
- имя темы. Теперь тема доступна для установки:
1
|
|
После чего заново генерируем сайт:
1
|
|
В качестве платформы для сайта я решил выбрать GitHub, тому есть два аргумента, которые оказались лично для меня важными:
- бесплатный,
- поддерживает CNAME
*
* Поддежка CNAME
позволяет прикреплять произвольный домен к репозиторию.
Описывать регистрацию на GitHub я не буду. Но опишу процесс создания репозитория. После того как вы зарегистрируетесь, создайте репозиторий (рис. 1):
Хочу обратить ваше внимание, что имя сайта должно быть идентично имени пользователя.
После того как вы создадите репозиторий, система перенаправит вас на страницу с репозиторием. Так как репозиторий пуст, система покажет небольшую инструкцию с вариантами заполнения репозитория. В случае с Octopress, процессом выгрузки управляет специальный скрипт. Потому мы можем переходить к следующему шагу.
Для выгрузки в репозиторий используется публичный SSH-ключ. Его можно добавить как в настройках репозитория (рис. 3, рис. 4), так и в настроках профиля. Если вы добавите ключ только для репозитория, он будет использоватся лишь для работы с указанным репозиторием.
Если у вас ещё нет публичного SSH-ключа, самое время создать его. Как это сделать, вы можете посмотреть здесь.
Теперь свяжем созданный выше репозиторий с каталогом Octopress. Для этого запустим команду setup_github_pages
. В процессе команда запросит адрес репозитория, пример адреса показан на рис. 3.
1 2 3 4 5 |
|
Если вы все сделали верно, значит у вас настроена выгрузка в ваш репозиторий на GitHub.
Основные настройки хранятся в файле _config.yml. Сам файл расположен в корневой папке Octopress. Ниже приведу содержимое этого файла с комментариями.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 |
|
Комментарии переведены не до конца. Пользуюсь машинным переводом, но он не всегда может помочь. Со временем перевод конечно же будет закончен. Но если найдутся желающие помочь с переводом, буду рад.
Процедура создания новых сообщений/страниц, достаточна проста. Вы можете указывать имя на кириллице, скрипт автоматически переведет название в транслит и укажет полученное название в имени файла. Если в имени нового сообщения/статьи есть пробелы, необходимо использовать кавычки. Несмотря на то, что в справке это не упоминается.
Новые сообщения создаются в каталоге octopress/source/_posts
и имеют формат имени YYYY-MM-DD-post-name.markdown
:
1 2 3 |
|
Созданный файл имеет следующую структуру:
1 2 3 4 5 6 7 |
|
Это каркас сообщения. Настройки интуитивно понятны, можно разрешить/запретить комментарии, указать категорию (можно указать несколько категорий), функционал аналогичен функционалу тегов. Для разделения короткого и полного текста используется тег <!-- more -->
.
Для новых страниц создается новый каталог с именем создаваемой страницы. К примеру создаем новую страницу:
1 2 3 |
|
В результате будет создан каталог, а уже в этом каталоге будет создан файл index.markdown
со следующим содержимым:
1 2 3 4 5 6 7 8 |
|
Для создаваемых страниц я обычно отключаю комментарии, подвал и прочее. Для форматирования текста используется markdown.
В документации Octopress на сайте разработчиков перечислены лишь несколько команд для rake: generate
, deploy
, new_post
, new_page
и др. На самом деле у rake
для Octopress команд больше, посмотреть их список можно с помощью - rake list
, а получить список с описанием команд можно вот так - rake -T
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
Перевел в меру своих сил, если встретите неточность, пишите в комментариях.
К сожалению, Octopress не имеет локализации на русском языке. Но этот недостаток легко можно исправить вручную. Я ищу текст который нужно перевести с помощью команды grep
.
1
|
|
Где comments
- слово которое надо перевести, а source
- каталог поиска.
Поиск должен проводиться в каталоге с файлами Octopress. Вы так же можете
переделать саму тему. И при последующей установке темы у вас уже будет сайт на
русском языке.
Для локализации дат, надо заменить содержимое файла:
1
|
|
на это. А содержимое файла:
1
|
|
на это.
]]>Перед всеми системными администраторами возникает задача резервного копирования баз данных (БД). Поэтому хочу поделится с вами скриптом для резервного копирования БД PostgreSQL. И его довольно просто переделать для любой другой СУБД. Данный скрипт неплохо подойдет новичкам. На нашем форуме есть вариант скрипта для резерного копирования БД MySQL.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
Хочу напомнить, что данный скрипт нужно выполнять от имени пользователя postgres. Неиспользуемые переменные закомментированы, при желании можно их удалить.
Восстановить дамп можно командой:
1
|
|
Где archname
- имя резервной копии (дампа), а dbname
- имя существующей БД в PostgreSQL. Если хотите восстановить дамп в новую БД, то создать ее можно командой:
1
|
|
Опять же, команду необходимо выполнять от имени postgres.
Теперь осталось настроить время запуска скрипта. В этом нам поможет cron. Мне необходимо чтобы скрипт запускался:
- ежедневно в 22:30, с понедельника по пятницу,
- ежемесячно в 23:30, в первую субботу месяца.
Кроме того, ежедневные и ежемесячные копии должны хранится отдельно. Соответственно нам потребуются две копии скрипта, в каждной укажем необходимый путь для резерных копий:
1 2 |
|
С помощью команды crontab
:
1
|
|
Добавим в список заданий пару строк в самый конец файла:
1 2 |
|
Где postgres
- пользователь, от имени которого будет запускаться скрипт, path
- путь до каталога со скриптами, а psql_dayli-backup.sh
и psql_monthly-backup.sh
- имена файлов со скриптом.
На данный момент производительность PostgreSQL в связке с сервером 1С:Предприятия в сравнении с тем же MS SQL оставляет желать лучшего. Эта статья продолжение попыток добиться достойной производительности на PostgreSQL. Хотя на данный момент у меня не получилось добиться производительности сопоставимой MS SQL, но думаю в недалеком будущем эта проблема будет решена.
Далее в статье перечислены основные параметы и особенности, на которые следует обратить внимание при оптимизации PostgreSQL.
Объём совместно используемой памяти, выделяемой PostgreSQL для кэширования данных, определяется числом страниц shared_buffers
по 8 килобайт каждая. Следует учитывать, что операционная система сама кэширует данные, поэтому нет необходимости отводить под кэш всю наличную оперативную память. Размер shared_buffers
зависит от многих факторов, для начала можно принять следующие значения:
Под каждый запрос выделяется ограниченный объём памяти. Этот объём используется для сортировки, объединения и других подобных операций. При превышении этого объёма сервер начинает использовать временные файлы на диске, что может существенно снизить производительность. Оценить необходимое значение для work_mem
можно разделив объём доступной памяти (физическая память минус объём занятый под другие программы и под совместно используемые страницы shared_buffers
) на максимальное число одновременно используемых активных соединений.
Эта память используется для выполнения операций по сбору статистики ANALYZE
, сборке мусора VACUUM
, создания индексов CREATE INDEX
и добавления внешних ключей. Размер памяти выделяемой под эти операции должен быть сравним с физическим размером самого большого индекса на диске.
PostgreSQL в своих планах опирается на кэширование файлов, осуществляемое операционной системой. Этот параметр соответствует максимальному размеру объекта, который может поместиться в системный кэш. Это значение используется только для оценки. effective_cache_size
можно установить в ½ - 2/3 от объёма имеющейся в наличии оперативной памяти, если вся она отдана в распоряжение PostgreSQL.
ВНИМАНИЕ! Следующие параметры могут существенно увеличить производительность работы PostgreSQL. Однако их рекомендуется использовать только если имеются надежные ИБП и программное обеспечение, завершающее работу системы при низком заряде батарей.
Данный параметр отвечает за сброс данных из кэша на диск при завершении транзакций. Если установить в этом параметре значение off
, то данные не будут записываться на дисковые накопители сразу после завершения операций. Это может существенно повысить скорость операций insert
и update
, но есть риск повредить базу, если произойдет сбой (неожиданное отключение питания, сбой ОС, сбой дисковой подсистемы).
Отрицательное влияние включенного fsync
можно уменьшить отключив его и положившись на надежность вашего оборудования. Или правильно подобрав параметр wal_sync_method
- метод, который используется для принудительной записи данных на диск.
Возможные значения:
open()
с параметром O_DSYNC
,fdatasync()
после каждого commit
,fsync()
после каждого commit
игнорирую параллельные процессы,fsync()
после каждого commit
,open()
с параметром O_SYNC
.ПРИМЕЧАНИЕ! Не все методы доступны на определенных платформах. Выбор метода зависит от операционной системы под управлением, которой работает PostgreSQL.
В состав PostgreSQL входит утилита pg_test_fsync, с помощью которой можно определить оптимальное значение параметра wal_sync_method
.
Она выполняет серию дисковых тестов с использованием различных методов синхронизации. В результате этого теста получаются оценки производительности дисковой системы, по которым можно определить оптимальный метод синхронизации для данной операционной системы.
Я решил провести вышеуказанный тест на своем рабочем компьютере, имеющем следующие характеристики:
Тест на Windows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|
По результатам теста мы видим, что для Windows оптимальным решением будет использование open_datasync
.
Тест на Linux:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|
По результатам теста мы видим, что наилучшую скорость выдают методы fdatasync
и open_datasync
. Так же можно заметить, что на же оборудовании Linux выдал скорость записи почти в половину больше, чем на Windows.
Следует учитывать, что в данных тестах использовалась дисковая система, состоящая из одного диска. При использовании RAID массива с большим количеством дисков картина может быть другой.
Количество памяти используемое в SHARED MEMORY
для ведения транзакционных логов. При доступной памяти 1-4 Гб рекомендуется устанавливать 256-1024 Кб. Этот параметр стоит увеличивать в системах с большим количеством модификаций таблиц базы данных.
Oпределяет количество сегментов (каждый по 16 МБ) лога транзакций между контрольными точками. Для баз данных с множеством модифицирующих данные транзакций рекомендуется увеличение этого параметра. Критерием достаточности количества сегментов является отсутствие в логе предупреждений (warning) о том, что контрольные точки происходят слишком часто.
Включение этого параметра гарантирует корректное восстановление, ценой увеличения записываемых данных в журнал транзакций. Отключение этого параметра ускоряет работу, но может привести к повреждению базы данных в случае системного сбоя или отключения питания.
Включает/выключает синхронную запись в лог-файлы после каждой транзакции. Включение синхронной записи защищает от возможной потери данных. Но, накладывает ограничение на пропускную способность сервера. Вы можете отключить синхронную запись, если вам необходимо обеспечить более высокую производительность по количеству транзакций. А потенциально низкая возможность потери небольшого количества изменений при крахе системы не критична. Для отключения синхронной записи установите значение off
в этом параметре.
Еще одним способом увеличения производительности работы PostgreSQL является перенос журнала транзакций (pg_xlog) на другой диск. Выделение для журнала транзакций отдельного дискового ресурса позволяет получить получить при этом существенный выигрыш в производительности 10%-12% для нагруженных OLTP систем.
В Linux это делается с помощью создания символьной ссылки на новое положение каталога с журналом транзакций.
В Windows можно использовать для этих целей утилиту Junction. Для этого надо:
C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog
.C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog
в D:\pg_xlog
и удалить C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog
.C:\Program Files\PostgreSQL\X.X.X\data
.C:\Program Files\PostgreSQL\X.X.X\data
и выполнить junction -s pg_xlog D:\pg_xlog
.D:\pg_xlog
пользователю postgres.X.X.X
- версия используемой PostgreSQL.В СУБД PostgreSQL реализована только частичная поддержка FULL OUTER JOIN
(ERROR: “FULL JOIN is only supported with mergejoinable join conditions”). Для реализации полной поддержки FULL OUTER JOIN
при работе 1С:Предприятия 8 с PostgreSQL подобный запрос трансформируется в другую форму с эквивалентным результатом, однако эффективность использования конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ
снижается.
В связи с этим не рекомендуется использовать ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ
при работе с PostgreSQL. В большинстве случаев без использования этой конструкции можно обойтись, переписав исходный запрос.
Проблема: При работе с PostgreSQL использование соединения с виртуальной таблицей СрезПоследних
может приводить к существенному снижению производительности. Из-за ошибки оптимизатора может быть выбран неоптимальный план выполнения запроса.
Решение: Если в запросе используется соединение с виртуальной таблицей языка запросов 1С:Предприятия СрезПоследних
и запрос работает с неудовлетворительной производительностью, то рекомендуется вынести обращение к виртуальной таблице в отдельный запрос с сохранением результатов во временной таблице.
При выполнения некоторых регламентных операций (Закрытие месяца, Расчет себестоимости и т.п.), где используются сложные запросы с большим количеством соединений больших таблиц, возможно существенное увеличение времени выполнения операции. В основном, эти проблемы связаны с работой оптимизатора PostgreSQL и отсутствием актуальной статистики по таблицам, участвующим в запросе.
Варианты решения проблемы:
ANALYZE
, но улучшат построение плана запроса:
default_statistics_target = 1000 -10000
.NESTED LOOP
при выборе плана выполнения запроса в конфигурации PostgreSQL:
enable_nestloop = off
.HASH JOIN
).join_collapse_limit=1
.seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025
AUTOVACUUM
сбор статистики, на основе информации об изменении данных в таблице. По умолчанию включен сбор статистики только для временных таблиц и во многих ситуациях этого достаточно. При возникновении проблем с производительностью выполнения регламентных операций, можно включить сбор статистики для всех или отдельных проблемных таблиц изменив значение параметра конфигурации PostgreSQL (файл postgresql.conf) online_analyze.table_type = "temporary"
на online_analyze.table_type = "all"
.После изменения этих параметров, следует оценить возможное влияние этих изменений на работу системы и выбрать наиболее приемлимый вариант для ваших задач.
Ко всему вышеперечисленному можно так же добавить:
Статья обновлена 8 октября 2016 года. Добавлены сравнительные тесты
]]>В конце мая 2013 года компания 1С представила первый стабильный релиз платформы 1С:Предприятие версии 8.3. Главная особенность ветки 8.3 - это выпуск нативного клиента под *nix-подобные операционные системы. И вот спустя два года я решил написать новую статью посвященную этой теме. Я помню, что большая часть тех, кому была интересна моя прошлая статья просили и дальше брать в основу Ubuntu. Тем не менее, я решил взять за основу Debian 8 «Jessie». Основная причина в том, что производительность серверов 1С:Предприятие на Ubuntu оставляет желать лучшего. В то время как Debian и CentOS показывают более высокую производительность (CentOS даже опережает Debian, но я постараюсь исправить это положение). Сравнительные таблицы производительности серверов 1С:Предприятие вы можете поискать в интернете. Сам я пока ничего толкового не нашел.
Новичкам в *nix рекомендую выполнять установку по порядку и согласно инструкции. Статья специально разбита на главы, чтобы читатели могли пошагово проходить процесс установки. Вопросы любителей сделать «по своему» в большинстве своем будут проигнорированы. Если же вы всё делали согласно статье, но тем не менее у вас возникла проблема, внимательно проверьте все свои действия. Скорее всего, вы допустили ошибку. В случае если проверка не выявила ошибок, то вы можете описать возникую проблему в комментариях или в теме на нашем форуме, где форумчане постараются вам помочь. При этом рекомендую подробно описывать возникшую у вас проблему.
Основное отличие Debian от Ubuntu с которым очень часто сталкиваются пользователи Ubuntu, это отсутствие в стандартной конфигурации команды повышения привилегий sudo
. Операции требующие прав root, выполняются от суперпользователя root. Тем же кто не хочет изменять своей привычке работать с sudo
, достаточно при установке ОС не задавать пароль суперпользователю root и пакет sudo будет установлен и настроен. Для наглядности, перед каждой командой будет указан определенный символ, если это #
- значит команда выполняется от имени суперпользователя root, если символ $
- то команда выполняется от имени текущего пользователя.
1. Итак у вас имеется установленный Debian 8. Если установка только предстоит, рекомендую выбрать пункты:
Как это указано на скриншоте:
Остальные пункты на ваше усмотрение.
2. Сразу же поставим последние обновления, предварительно получив права root:
1 2 3 4 |
|
3. Архивы с установочными пакетами можно скачать из интернета сразу на сервер или скопировать заранее скачанные установочные пакеты в расшаренный каталог samba. Предположу, что samba настроена не у всех, потому воспользуемся USB-накопителем (флешкой). Создаем в корне флешки каталоги:
1 2 3 |
|
Раскидываем пакеты по каталогам, предварительно распаковав их.
4. Создаем директорию, к которой будем монтировать флешку:
1
|
|
5. Подключаем флешку к серверу, просматриваем как она подключилась:
1 2 3 4 5 6 7 8 9 10 11 |
|
У меня это sdb4
, теперь монтируем флешку сразу в каталог 1сinstall:
1
|
|
6. Проверяем что намонтировали:
1
|
|
Т.к. на моей флешке ничего не было кроме папок с установочными пакетами, отобразились только они:
1 2 3 |
|
ПРИМЕЧАНИЕ! Если вы ставите 1С:Предприятие на удаленную машину, то для передачи файлов можете воспользоваться утилитой SCP, которая входит в состав пакета openssh-client.
Для корректной работы PostgreSQL в связке с 1С:Предприятие, необходимо провести ряд подготовительных процедур.
1. Для начала надо установить необходимые локали. Это en_US.UTF-8
и ru_RU.UTF-8
. При этом локаль ru_RU.UTF-8
должна быть выбрана по умолчанию. Отредактировать список локалей можно командой:
1
|
|
2. Затем надо установить зависимости:
1
|
|
3. К сожалению, мейнтейнеры работающие на 1С, не следят за порядком в зависимостях своих пакетов. По этой простой причине, нам надо скачать и установить пакет libicu48:
1 2 |
|
4. Так же необходимо увеличить максимальный размер сегмента памяти до 64 Мб:
1
|
|
Дабы необходимые изменения вступили в силу, вводим:
1
|
|
Тут товарищ Vasiliy P. Melnik в своем комментарии пишет, что в данной процедуре необходимости нет. Я его утверждение не проверял, но вы можете попробовать пропустить 4 пункт. А если всё таки процедура потребуется, вы можете выполнить её позже.
5. В этой статье я решил использовать версию PostgreSQL от 1С. Переходим в каталог с пакетами PostgreSQL:
1
|
|
Проверяем что есть в каталоге:
1 2 3 4 5 6 7 8 9 |
|
Всего 6 пакетов, которые и нужно установить. В каталоге addons, находятся дополнительные пакеты, их я ставить не буду.
1
|
|
После установки проверим, запустился ли сервис PostgreSQL:
1
|
|
Если пакеты были установлены правильно, то вы получите примерно следующее сообщение (выхлоп):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
Если же вы получите сообщение похожее на это:
1 2 3 4 5 |
|
Нас интересует последняя строчка, где сообщается, что кластер PostgreSQL не обнаружен. Чтобы исправить эту ситуацию, достаточно просто перезапустить сервис PostgreSQL:
1
|
|
После чего снова проверьте статус сервиса. В итоге вы должны получить что-то похожее на первое сообщение.
6. После установки нужно еще немного подправить конфигурационный файл. Как ни странно PostgreSQL будучи установленным из пакетов 1С, содержит неправильные настройки для обработки экранирующих символов, и при создании базы выдает ошибку:
1
|
|
или
1
|
|
Чтобы избежать вышеуказанных ошибок нужно отредактировать настройки PostgreSQL:
1
|
|
Приведя нижеуказанные параметры к следующему виду:
1 2 3 |
|
Обновим конфигурацию, не перезапуская сервис:
1
|
|
7. Зададим пароль внутреннему пользователю PostgreSQL, предварительно авторизировавшись под системным пользователем postgres. Итак, авторизация:
1
|
|
Переход в домашний каталог текущего пользователя:
1
|
|
Смена пароля у внутреннего пользователя PostgreSQL:
1
|
|
Где -U postgres
- системный пользователь от имени которого будет запущен psql
, user postgres
- внутренний пользователь БД, ну а 123456
- произвольный пароль который будет задан внутреннему пользователю БД.
Если смена пароля прошла успешно, вы должны получить сообщение:
1
|
|
Выход из окружения системного пользователя postgres:
1
|
|
8. Напоследок зафиксируем пакеты PostgreSQL, чтобы они не обновлялись из стандартных репозиториев:
1
|
|
Если команда выполнена правильно, вы должны получить следующее сообщение:
1 2 3 4 5 6 |
|
На этом установка PostgreSQL закончена. Вопросы настройки и оптимизации будут рассмотрены в отдельных статьях.
Теперь нам предстоит установка сервера 1С:Предприятие. Как и в случае с PostgreSQL нам предстоит ряд подготовительных работ необходимых для штатного функционирования сервера 1С:Предприятие.
1. Переходим в из каталога postgres в каталог 1c:
1
|
|
2. Устанавливаем дополнительные пакеты, которые необходимы для работы сервера:
1
|
|
3. Так как я не нашел достойной альтернативы пакету ttf2pt1, который не тянет кучу зависимостей. То я буду ставить его. В репозиториях его нету, скачаем из архива Debian:
1
|
|
Докачиваем libt1-5 от которого зависит ttf2pt1:
1
|
|
Устанавливаем пакеты:
1
|
|
Кстати, жду предложений по возможной альтернативе пакету ttf2pt1.
4. Посмотрим, какие пакеты есть у нас в каталоге:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Всего 8 пакетов, из которых нам для функционирования сервера 1С:Предприятия необходимы 3 пакета: 1c-enterprise83-common, 1c-enterprise83-server, 1c-enterprise83-ws.
Название пакета | Описание пакета |
---|---|
1c_enterprise83-client… | Компоненты клиента 1С Предприятие 8.3 для Linux |
1c_enterprise83-thin-client… | Компоненты тонкого клиента 1С Предприятие 8.3 для Linux |
1c_enterprise83-common… | Общие компоненты 1С Предприятие 8.3 для Linux |
1c_enterprise83-server… | Сервер 1С Предприятие 8.2 для Linux |
1c_enterprise83-ws… | Компоненты интернет-сервисов 1С Предприятие 8.3 для Linux |
1c_enterprise83-…-nls… | Компоненты необходимые для ОС не поддерживающих кириллическую кодировку |
5. Устанавливаем необходимые пакеты:
1
|
|
6. Даем пользователю usr1cv8 и группе grp1cv8 права на установочную директорию 1С:Предприятия:
1
|
|
7. В выхлопе установщика вы можете заметить предупреждение:
1 2 3 |
|
Начиная с версий 8.3.7, данная проблема исправлена. Потому, если вышеуказанного сообщения вы не получали, можете пропустить пункты 8 и 9.
8. Сообщение описанное в пункте 7 мы получаем из-за отсутствия в скрипте запуска LSB-тегов. Ошибка не критична и никак не повлияет на работу сервера 1С:Предприятие. Но её легко можно решить, для этого добавим LSB-теги в сценарий сервиса 1С:Предприятие:
1
|
|
Находим строки:
#!/bin/bash
#------------------------------------------------------------
# 1C:Enterprise server configuration parameters
#------------------------------------------------------------
# 1C:Enterprise server keytab file.
Приводим к следующему виду:
#!/bin/bash
#------------------------------------------------------------
# 1C:Enterprise server configuration parameters
#------------------------------------------------------------
### BEGIN INIT INFO
# Provides: srv1cv83
# Required-Start: $remote_fs $network $syslog $named
# Required-Stop: $remote_fs $network $syslog $named
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Description: 1C:Enterprise 83 server.
### END INIT INFO
# 1C:Enterprise server keytab file.
После изменения сценария, запускаем:
1
|
|
9. Перезапускаем службу сервера 1С:Предприятие:
1
|
|
10. Проверяем запускаются ли при старте системы сервер 1С:Предприятие:
1
|
|
Вы должны получить примерно такое сообщение:
1 2 3 |
|
11. Так же для профилактики можно проверить, все ли процессы сервера запущены:
1
|
|
От имени пользователя usr1cv8 должно быть запущено три процесса: ragent, rmngr и rphost. После имен процессов идут номера портов, через которые они работают:
1 2 3 4 |
|
Большая часть новичков впервые столкнувшиеся с процессом установки 1С:Предприятие не могут понять о какой лицензии, ключе, HASP идет речь. Итак, лицензия 1С необходима для запуска продуктов 1С:Предприятие. Лицензии 1С можно разделить на аппаратные и программные. Мы рассмотрим аппаратную лицензию (USB-токен)). Аппаратные ключи 1С делятся на 3 вида и их можно отличить по цвету:
Клиентское приложение допускает использование следующих ключей HASP:
Причём на одном компьютере может быть установлено не более одного ключа одной серии. Подробнее о видах лицензии и ключей вы можете прочитать здесь.
Из вышеуказанного следует - нам нужны два типа лицензий. Лицензия для сервера 1С:Предприятие и лицензия для клиента 1С:Предприятие. После того как мы выяснили какие ключи нам необходимы, можно перейти к установке драйвера. Свежий драйвер можно скачать на официальном сайте. Большинству подойдет HASP 4, его и скачивайте.
1. Как вы помните, всё необходимое я уже скачал, потому просто переходим из каталога 1с, в каталог hasp:
1
|
|
Проверим, что есть в каталоге:
1 2 3 4 |
|
Установочный пакет есть, осталось установить его:
1
|
|
2. После установки сервис не запустился, запустим его:
1
|
|
Если сервис запустился штатно, команда просто отработает не выдав сообщений. Проверить запущен ли сервис можно командой:
1
|
|
Вы должны получить сообщение:
1 2 3 4 5 6 7 8 |
|
ПРЕДУПРЕЖДЕНИЕ! Для 64-битного сервера 1С:Предприятие, нужен 64-битный серверный HASP-ключ. 32-битный серверный HASP-ключ с 64-битным сервером 1С:Предприятие работать не будет!
ПРИМЕЧАНИЕ! Сервер 1С:Предприятие под *nix-подобные операционные системы не требует наличия серверного ключа, если число пользользователей не превышает 12. В этом случае требуется наличие только клиентских лицензий. Тем не менее, согласно правилам лицензирования, организация должна приобрести серверный ключ.
На этом установка драйвера закончена.
Итак, дано: рабочая станция с Debian 8 «Jessie» + DE Cinnamon на борту. Я предпочел Cinnamon, но каждый может выбрать окружение (DE) себе по вкусу. Можно приступить к установке клиента 1С:Предприятие.
1. По уже заведенной традиции, устанавливаем дополнительные пакеты, необходимые для работы 1С:Предприятие:
1
|
|
2. На памятной флешке, имеются также пакеты клиента. Подключим флешку как указано в пунктах 4 и 5, главы Подготовка сервера и сразу перейдем в каталог с пакетами 1С:Предприятие:
1
|
|
Посмотрим, что имеется в каталоге:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
3. Есть два варианта установки клиента. Первый вариант - установка полноценного клиента (включает толстый и тонкий клиенты), второй вариант - установка тонкого клиента. В случае с установкой полноценного клиента, необходимо также устанавливать и серверную часть.
3.1. Сначала рассмотрим установку полноценного клиента:
1
|
|
После чего надо выполнить процедуры указанные в пунктах с 6 по 9, главы Установка сервера 1С:Предприятие 8.3.
3.2. Тонкий клиент, можно устанавливать на те машины, где не планируется использование толстого клиента. Преимущество тонкого клиента, это отсутствие зависимостей от компонентов сервера 1С:Предприятие, а также возможность работать через интернет. Итак, установка тонкого клиента:
1
|
|
В каких случаях нам необходим толстый клиент?
- Работа с конфигуратором,
- Создание информационных баз,
- Проведение объемных вычислений (в случае толстого клиента, все вычисления проводятся на стороне клиента).
Подробнее о тонких и толстых клиентах можно почитать здесь.
4. Теперь нам необходимо выбрать каким способом мы будем взаимодействовать с сервером. В зависимости от обстоятельств и предпочтений, вы можете установить DNS-сервер, или прописывать имя сервера на каждой клиентской машине вручную:
1
|
|
Надо добавить строку:
1
|
|
Где 192.168.1.1
- IP-адрес сервера, as1
- имя сервера, as1.nixway.loc
- имя сервера в локальном домене, его указывать не обязательно.
5. После того как вы добавили вышеуказанную строку, проверьте, доступен ли сервер по указанному имени:
1
|
|
Вы должны получить примерно такой ответ:
1 2 3 4 5 6 7 8 9 |
|
Установка клиента закончена, можно приступать к созданию информационной базы.
Для начала можно (но совсем необязательно) установить демонстрационную конфигурацию. Дабы продемострировать работую так называемого «Управляемого приложения». Демонстрационная конфигурация идет в комплекте с 1С:Предприятие 8.3. Установщик конфигурации представлен в виде простого скрипта. Потому, описывать процесс установки я не буду, просто выложу несколько скриншотов процесса установки:
1. Создание информационных баз на *nix-подобных ОС должно проходить из под толстого клиента. В противном случае вы рискуете получить ошибку:
Кроме вышеуказанной ошибки, встречается и другая, но уже в толстом клиенте. Когда при добавлении новой ИБ 1С:Предприятие выдает сообщение:
ИБ создается, но 1С:Предприятие некорректно обрабатывает её создание. В этом случае достаточно просто добавить ИБ в список:
Вышеуказанные ошибки будут рассмотрены в отдельной статье.
2. При первом запуске 1С:Предприятие сразу же предлагает нам добавить информационную базу (ИБ), жмем Да:
3. Выбираем пункт Создание новой информационной базы, жмем Далее >:
4. Выбраем шаблон конфигурации для создаваемой ИБ или же создаем ИБ без конфигурации, жмем Далее >:
5. Задаем имя ИБ и выбираем пункт На сервере 1С:Предприятия, жмем Далее >:
6. По порядку указываем: доменное имя или IP-адрес сервера 1С:Предприятие, имя ИБ, параметры соединения, тип СУБД, адрес сервера баз данных (БД), имя БД на сервере БД, имя пользователя сервера БД, пароль пользователя сервера БД, жмем Далее >:
7. Параметры запуска оставляем без изменений, жмем Готово:
8. Если вы всё сделали правильно, то через некоторое время ИБ будет создана и вы увидите её в списке:
9. Теперь, когда мы создали ИБ, можно её запустить. Как вы помните, я создавал ИБ из шаблона демонстрационной конфигурации. Так выглядит рабочее окно этой конфигурации:
Ну и конечно же конфигуратор:
Хочу обрадовать тех, кому не хватало возможности публикации информационной базы на веб-сервере Apache. Добавление поддержки последней версии Apache, я заметил при установке 1С:Предприятие версии 8.3.8.1652. Может поддержка Apache 2.4 появилась и раньше. Но проверять мне было лень, а новостей на эту тему я не нашел. Даже на официальном сайте 1С, на данный момент устаревшая информация. Процесс публикации не изменился. Обращаю особое внимание, что процесс установки описан для Apache не ниже 2.4.
Создаем директорию для vrd-файла:
1
|
|
А также файл конфигурации Apache:
1
|
|
Переходим в каталог со утилитой публикации веб-клиента:
1
|
|
Запускаем утилиту:
1
|
|
Где /var/www/ib/ibname
- директория где будет создан vrd-файл, ibname
- имя ИБ, as1.nixway.loc
- адрес сервера 1С:Предпрятие, а /etc/apache2/conf-available/ibname.conf
- путь до конфигурационного файла Apache.
Подключаем конфигурацию:
1
|
|
Перечитываем конфигурацию Apache:
1
|
|
Если процедура публикации была проведена корректно, ИБ будет доступна по адресу:
1
|
|
Прошу в комментариях задавать вопросы только по статье. Если же вы найдете в статье ошибку или у вас есть предложения, просьбы, вопросы выходящие за рамки статьи, можете оставлять их на нашем форуме, в специально созданной теме.
Напоминаю копипастерам, использование прямой ссылки на оригинальную статью обязательно.
Статья обновлена 10 августа 2016 года.
]]>На данный момент доступна только альфа-версия, несмотря на это продукт уже достаточно стабилен. К тому же ведется ведется активная разработка. Официально поддерживается только английский и китайские языки, но к нашей радости имеется сообщество, отдельные преставители которого занимаются переводом и созданием словарей.
Не думаю, что процесс установки вызовет сложности, т.к. доступны установочные пакеты для большинства популярных *nix-подобных ОС. К сожалению готовых установочных пакетов с локализациями, словарями и шрифтами нет. Но, я готов предоставить пакеты, которые собирал для себя:
* В состав пакета входят шрифты: Calibri, Cambria, MT-Extra, Symbol, Webdings, Wingding 1, Wingding 2, Wingding 3.
Первым что бросается в глаза, так это интерфейс в стиле Ribbon. На первый взгляд выглядит все просто замечательно, но по мере работы с пакетом начинаешь понимать, что не всё так радужно. К примеру, панель быстрого доступа ограничена по функционалу. Она недоступна через горячие клавиши, на неё нельзя назначить нужный функционал, кроме заданного разработчиками. А ведь это очень удобно, вывести на панель наиболее часто используемый функционал и вызывать его горячими клавишами, не переключаясь по вкладкам.
Далее рассмотрим функционал Backstage. В WPS Office он имеет двойное назначение и это видно по самой кнопке. Сама кнопка, предоставляет крайне скудный функционал:
Несравнимый с функционалом предоставляемым MS Office Backstage:
Те, кто работал в MS Office 2007 и выше, поймут насколько удобнее меню Backstage от MS. Стрелка находящаяся справа от кнопки, предоставляет доступ к меню. Его вы можете увидет на изображении ниже.
Явные на мой взгляд недостатки я перечислил. Теперь давайте рассмотрим особенности и отличия. Самой заметной особенностью, является поддержка стилей интерфейса. Стоит отдельно отметить наличие стиля “Классического интефейса”. Поменять стиль интерфейса вы можете через меню (Сервис » Поменять стиль интерфейса) или через кнопку в заголовке окна:
Ещё одной отличительной чертой являются вкладки, которые я считаю довольно удобным решением. Кроме того, на приветственной странице, пользователю предлагается набор шаблонов на любой вкус:
По поводу заявлениянной поддержки форматов *.docx, *.xlsx, *.pptx, я ничего сказать не могу. На данный момент я не работаю со сложными документами в этих форматах. И даже, если поддержка вышеперечисленных форматов соответствует заявленному, многих огорчит отсутствие поддержки ODF.
Итак, что представляет из себя Kingsoft WPS Office? ИМХО, это попытка создать альтернативу популярнейшему пакету офисных програм. Но, на данный момент продукт не может конкурировать ни с Microsoft Office, ни даже с LibreOffice. Кому же подойдет этот пакет? Думаю, тем кто привык к ленточному интерфейсу и никогда не работал с классическим интерфейсом. Ведь как я уже писал выше, ленточный интерфейс в этом продукте крайне скуден на функционал и настройки.
Конечно же не стоит ставить крест на этом продукте. Работа над ним продолжается и быть может в будущем, продукт сможет приятно удивить пользователей функционалом и удобным интерфейсом. Ну а на данный момент времени, мне больше подходит LibreOffice.
]]>В сети очень много статей на тему установки и настройки DNS-сервера Bind9. Они разные. Некоторые написаны просто и доступно, но нет пояснений зачем и почему. В других материал подан очень подробно, но новичкам такой материал осилить сложно. Я же попытаюсь совместить достоинства способов подачи материала, нащупать ту золотую середину, которая подойден большинству. Но опять таки, я не претендую на истину в последней инстанции и готов принять конструктивную критику.
Итак, вступление закончено, приступим к самой статье. Я как приверженнец Debian, буду описывать процесс установки и настройки именно на этой ОС. Дано Debian 8 «Jessie» установленный вот с такими параметрами (Ну разве кроме пункта web server, он пригодится тем, кто в дальнейшем будет работать с веб-сервером Apache):
1 2 3 |
|
Для решения данной задачи настроим сервер таким образом, чтобы при обращении по доменному имени внутри сети он отвечал по локальному адресу. Все комманды выполняются от имени суперпользователя (root).
Сначала установим необходимые пакеты:
1
|
|
Теперь необходимо настроить файл конфигурации Bind9:
1
|
|
Приведём его к следующему виду:
1 2 3 4 5 6 7 8 |
|
Расшифровка:
acl
- создает ACL (Access control list) - так называемый список контроля доступа, с помощью которого мы ограничиваем диапазон адресов которые могут запрашивать зоны с нашего сервера. В данном примере это разрешено подсети 192.168.1.0/24
. и локальному хосту.
allow-query { mynetwork; };
- список тех, кто имеет право запрашивать информацию. Можно ограничить с помошью acl либо установить allow-query { any; };
- что будет означать, что запросы разрешенмы всем.
forwarders {192.168.1.1; 8.8.8.8; };
- это DNS провайдера, или любые другие, у которых можно получить информацию о доменах неизвестных вашему серверу.
listen-on-v6 { none; }
- запрещает работать с IPv6.
Для начала покорректируем файл локальной конфигурации Bind9:
1
|
|
Этот файл содержит локальную конфигурацию DNS-сервера, в нем объявляются зоны, связанные с доменами этого сервера. Добавляем в него файлы наших зон (зону прямого просмотра и зону обратного просмотра):
1 2 3 4 5 6 7 8 9 10 |
|
Зона в DNS — это часть пространства имён DNS, управляемая конкретным сервером или группой серверов DNS. Зона прямого просмотра - это тип зоны в которой доменное имя преобразуется в IP-адрес. Создадим файл для зоны прямого просмотра:
1
|
|
Со следующим содержимым:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
В конце этого файла нужно обязательно оставить пустую строку!
Расшифровка:
$ORIGIN
- оригинальное имя зоны
ns1.nixway.loc.
- Наш DNS-сервер (точка в конце обязательна).
admin.nixway.loc.
- email администратора сервера, где вместо символа @ используется точка.
Serial
- серийный номер зоны в формате ГГГГММДД и номер текущего изменения за этот день. (Важно, при каждом изменении, нужно редактировать этот номер увеличивая его в большую сторону) Пример: 2015020301.
Refresh
- период времени с которым вторичный сервер днс обращается к основному.
Retry
- период с которым вторичный сервер будет повторять попытки при неудачном обновлении.
Expire
- максимальное время использования данных на вторичном сервере, после которого делается обязательное обновление.
Negative Cache TTL
- время актуальности данных в кэше запросов.
Далее идут записи имён хостов с ip-адресами или псевдонимами.
ns.provider.org.
- вместо этой записи можете указать NS вашего регистратора либо Free DNS сервиса.
Зона обратного просмотра, выполняет преобразование IP-адреса в доменное имя. Создадим файл для зоны обратного просмотра:
1
|
|
И запишем туда следующее:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
В этом файле должны быть только записи типа PTR
. В конце этого файла так же должна быть пустая строка. Число 10
- это последний октет в IP адресе нашего сервера.
Например, можно добавить в файл зоны прямого просмотра строку:
1
|
|
А в файл зоны обратного просмотра строку:
1
|
|
Тогда по адресу router.nixway.loc
в браузере будет открываться web-интерфейс роутера (эквивалентно 192.168.1.1), но только внутри локальной сети.
Проверим файлы зон на наличие ошибок командой:
1
|
|
Если ошибок нет, обновим информацию о зонах:
1
|
|
Теперь необходимо отредактировать resolv.conf:
1
|
|
Приводим его в следующий вид:
1 2 3 4 |
|
Проверку можно сделать двумя командами:
1 2 |
|
Которые должны выдать cледующий результат:
1 2 |
|
Если DHCP у вас раздает роутер, не забудьте установить выдаваемые по умолчанию DNS сервера 192.168.1.10 и 192.168.1.1 Проверьте корректность работы, введя в консоли Windows-машины
1
|
|
Если маршрут пошел сразу на адрес 192.168.1.10, значит все работает корректно. Если нет, пропробуйте очистить кэш DNS и посторить еще раз:
1
|
|
Не забудьте пробросить необходимые порты на роутере, если это необходимо конечно.
Обсуждение статьи на форуме.
]]>После выпуска Skype версии 4.3 для Linux, многие поклонники Linux столкнулись с проблемой работы микрофона в вышеупомянутом Skype. Недавно нашел более-менее универсальное решение. Оно должно подойти всем, у кого микрофон в системе работает.
Нам понадобится Pavucontrol.
PulseAudio Volume Control (pavucontrol) - простая утилита управления звуком (микшер). В отличие от классического микшера, он позволяет управлять звуком для устройства и каждого потока воспроизведения раздельно. Также позволяет перенаправлять поток на другой выход не прерывая воспроизведение.
Не сомневаюсь, те у кого Pavucontrol не установлен, прекрасно справится с его установкой. :) Потому описывать процесс установку я не буду.
В данный пост я буду собирать решения всех возможных проблем, которые я встречу знакомясь с Octopress.
В случае если команда rake generate
ошибку:
1
|
|
Надо найти и исправить:
1
|
|
На:
1
|
|
В следующих файлах:
1 2 3 |
|
Вышеуказанные файлы находятся в каталоге Octopress.
]]>Решил сделать для себя поборку наиболее понравившихся тем Octopress. Надеюсь эта подборка понравится и вам. В комментариях можете делиться своим списком тем. Вполне возможно, я пропустил немало интересных тем.
1. Приятная минималистичная тема Slash, в серых тонах.
2. Строгая тема Simplified, в оранжево-коричневых тонах. Яркая, но в то же время не режет глаза.
3. Светлая тема Whitespace, в серых оттенках, не напрягает. Но в этой теме для меня есть существенный недостаток, а именно использование шрифтов не поддерживающих кириллицу.
4. Отличная серо-зеленая тема Jin, автор lijinma.
Это руководство открывает серию материалов по установке известных систем управления содержимым (CMS) на веб-сервер nginx. В отдельную статью необходимо выделить общую часть, которая будет одинаковой для всех CMS, написанных на PHP (грубо говоря мы сделаем тот же LAMP, только вместо громоздкого и неповоротливого веб-сервера Apache у нас будет nginx). Задача данного руководства – установка веб-сервера nginx, системы управления базами данных MySQL и менеджера процессов FastCGI (FPM), а также их настройка.
* Конфигурация и установка отдельных CMS будут описаны в дополнительных материалах.
Все приведенные ниже инструкции сначала были выполнены.
Небольшие пояснения:
- символ #
(решётка) - означает выполнение команды от root (суперпользователя)
- cat /path/to/some.file
- означает что ниже приведено полное содержимое файла some.file
, расположенного в каталоге /path/to
- nano /path/to/some.file
- означает что надо отредактировать часть файла как указанно
- в процессе установки MySQL будет произведена предварительная настройка и задан пароль root.
Gentoo:
1 2 |
|
Вначале необходимо произвести начальную настройку MySQL:
1
|
|
Debian:
1 2 3 4 |
|
1
|
|
CentOS. Тут надо заметить, что в своих репозиториях CentOS нет nginx, поэтому добавим репозиторий:
1 2 3 4 5 6 7 |
|
1
|
|
Настроить MySQL:
1 2 |
|
Управление сервисами MySQL, nginx, PHP-FPM и добавление их в автозагрузку:
Gentoo:
1 2 3 4 5 6 7 |
|
Debian:
1 2 3 4 5 6 7 |
|
CentOS:
1 2 3 4 5 6 7 |
|
Сразу после установки nginx понимает только статические файлы, не исполняемые на сервере, и, если установка прошла успешно, запустив его можно проверить отображение «Welcome to nginx!» на localhost
(127.0.0.1
):
Впрочем может быть и так:
Это означает, что сервер не настроен.
Настройки по умолчанию подходят для большинства случаев и не требуют больших изменений на данном этапе. В различных дистрибутивах Linux настройки и месторасположение конфигурационных файлов могут различаться (также это замечание относится к использованию пакетов, установленных из репозиториев, отличных от основного), здесь всё зависит от поддерживающего пакет мейнтейнера.
Неизменным остаётся расположение файла настроек /etc/nginx/nginx.conf
. Конфигурации сайтов, дополнительные параметры добавляются в него через опцию include
.
В Debian например сейчас конфигурации сайтов добавляются в стиле Apache (добавление конфигурации созданием симлинков):
1 2 3 4 |
|
В официальных репозиториях этого нововведения нет и конфигурации сайтов добавляются следующим образов:
1 2 3 |
|
То есть любой файл из каталога /etc/nginx/conf.d/
с расширением .conf
будет добавлен.
Если каталог /etc/nginx/conf.d
- отсутствует, создайте его:
1
|
|
В include
как правило присутствует конфигурация сайта по умолчанию, который как раз и выводит надпись «Welcome to nginx!» при обращении к localhost
(127.0.0.1
):
- Debian/Ubuntu - /etc/nginx/sites-enabled/default
- Gentoo/CentOS - /etc/nginx/conf.d/default
- Больше этот файл не нужен - удалите его.
Создаем (если не существует) каталог для сайтов и устанавливаем права:
1 2 3 |
|
Владельцем каталога сайтов должен быть пользователь, от имени которого запущен и работает вэб-сервер. В Debian и Ubuntu это www‑data, в Gentoo, CentOS - пользователь nginx. В конфигурации за это отвечает директива user
(nginx.conf):
1 2 3 |
|
При переносе сайта, а также чтобы был доступ к содержимому сайта у пользователей, входящих в группу www‑data необходимы корректные права на содержимое. Права на каталоги 775
, на файлы 664
:
1 2 |
|
И добавить себя в группу www‑data или nginx в зависимости от дистрибутива:
1
|
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
|
* Важно - дополнительные пояснения - FastCGI (PHP FPM) для nginx
* Связку nginx и PHP-FPM настраиваем на работу через unix сокет
Создадим новую конфигурацию для localhost:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
и тестовый php-файл в корне
1 2 3 4 |
|
Gentoo:
1
|
|
Debian:
1
|
|
CentOS:
1
|
|
Отредактируем в этом файле следующие переменные, listen
:
1 2 3 4 5 |
|
user
, group
:
* В CentOS и Gentoo - nginx, Debian/Ubuntu - www‑data
1 2 3 4 5 |
|
* в этом файле комментариями является любой текст после символа ;
(точка с запятой).
После чего перегружаем nginx и PHP-FPM.
Открываем браузер и заходим на localhost
, в результате мы должны увидеть тестовую страницу PHP:
Версия nginx на момент написания - стабильная - nginx/1.4.1, но это в репозитории самого nginx, в репозиториях дистрибутивов версии более ранние, и поэтому могут возникнуть небольшие нестыковки, например в openSUSE 12.3 - версия nginx/1.2.9 и это руководство почти полностью подходит, но необходимо использовать /etc/nginx/fastcgi_params
отсюда.
nginx: http://nginx.org/ru/
nginx Wiki: http://wiki.nginx.org/nginxRu
PHP: http://www.php.net/
PHP-FPM: http://php-fpm.org/
MySQL: http://www.mysql.com/
Автор статьи zenon, и изначально он выкладывал её здесь. У себя я публикую статью с разрешения автора и с сохранением авторства.
]]>FastCGI это высокопроизводительный и масштабируемый интерфейс для взаимодействия веб-сервера и приложений, дальнейшее развитие технологии CGI, однако CGI-скрипты перезапускаются с каждым запросом сервера, что существенно снижает производительность; FastCGI оставляет процессы запущенными и только передает им новые запросы.
nginx имеет собственную поддержку технологии FastCGI для работы с внешними серверами и утилитами. PHP тоже поддерживает FastCGI и может быть использован для обработки FastCGI-запросов от nginx.
В данном примере мы рассмотрим связку nginx и PHP-FPM. Для начала необходимо их установить, в большинстве дистрибутивах для установки есть пакеты с одноимёнными названиями. Или, например в Gentoo, для установки необходим USE
флаг fpm
, более подробно смотрите в документации к своему дистрибутиву.
Есть много руководств по настройке nginx для работы с PHP FPM, но многие из них являются неполными (неправильно обрабатывается переменная PATH_INFO
) или содержат ошибки в обработке сценариев безопасности (отсутствует проверка наличия PHP кода в php файле).
Настроить подключение nginx и PHP-FPM можно двумя способами - либо через TCP‑порт (127.0.0.1:9000
), либо unix сокет (/var/run/php-fpm.sock
).
Первая рекомендация - храните все типовые настройки FastCGI в отдельном файле и, при необходимости, импортируйте их.
Например для Debian и Ubuntu настройки по умолчанию находятся в файле /etc/nginx/fastcgi_params
, который должен выглядеть следующим образом:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
Тут мы должны сказать Nginx`у, чтобы проксировал запросы к PHP FPM через протокол FCGI:
1 2 3 4 5 6 7 8 9 10 |
|
В параметрах php-fpm.conf
за подключение отвечает параметр listen
.
1 2 3 4 |
|
В варианте подключения через unix сокет fastcgi_pass
будет таким:
1
|
|
А параметр listen
вот так:
1 2 3 4 |
|
После изменения настроек перезапустите nginx.
Создайте файл test.php
в корневом каталоге nginx следующего содержания:
1
|
|
В браузере сделайте запрос:
1 2 3 4 5 |
|
Обратите внимание на значение REQUEST_URI
, SCRIPT_NAME
, PATH_INFO
и PHP_SELF
.
Вот правильный вывод для
1
|
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
Необходимые условия:
- Требования к PHP - версия 5.3.3 или выше.
- В php.ini значение cgi.fix_pathinfo = 1
(в некоторых мануалах советуют cgi.fix_pathinfo = 0
что может привести к не правильной обработке переменной PHP_SELF
не равной DOCUMENT_URI
).
- Регулярное выражение fastcgi_split_path_info
должно корректно обрабатывать запросы, такие как /test.php/foo/blah.php
или /test.php/
.
- Необходимо разрешить nginx'у проверку *.php
файлов чтобы предотвратить возможность передачи любых других файлов через PHP-FPM (например загруженные картинки).
Ознакомиться с более подробной информацией о FastCGI вы можете на официальном сайте.
]]>