Октябрь | 2015 | Информационный портал К2®

Monthly Archives: Октябрь 2015

Собственный хостинг репозиториев с помощью GitLab

Posted on 31.10.2015 by rudjuk Leave a comment

Любая команда разработчиков рано или поздно сталкивается с необходимостью использования системы контроля версий. Иначе отслеживать изменения в коде проектов становится сложно. Причем чем крупнее проекты и команды — тем сложнее. Сегодня систем контроля версий существует великое множество, одна лучше другой. Так что же выбрать? Наша команда остановилась на GitLab.

GitLab — это веб-приложение для хостинга исходного кода проектов, основанное на системе контроля версий Git. Своим функционалом GitLab очень напоминает GitHub, однако заточен под командную работу, в то время как GitHub отдает предпочтение индивидуальной работе.

Страница прав доступа к проекту

Техническая справка

Git — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. Git используют такие проекты, как Chromium, jQuery, PHP, MediaWiki и прочие. Программа является свободной и выпущена под лицензией GNU GPL версии 2.

— Статья о Git на Википедии

GitLab существует как в виде SAAS — веб-сайта с открытой регистрацией, так и в качестве индивидуального решения — GitLab Community Edition, которое можно установить на свой сервер и настроить под собственные нужды. Процесс установки достаточно долгий и требует root-доступа к серверу. Для стабильной работы GitLab требует от сервера как минимум двухъядерный процессор и 2 Гб ОЗУ. Такая конфигурация обеспечит быструю работу приложения и поддержку до 500 пользователей. GitLab поддерживает множество различных дистрибутивов Linux, но инструкция по установке расчитана на Debian/Ubuntu.

Установка

Установку можно разбить на несколько этапов:

установка необходимых системных утилит
установка Ruby
создание пользователя для SSH-подключений к GitLab
установка и настройка GitLab Shell
установка и настройка базы данных
установка и настройка самого GitLab
установка и настройка Nginx

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

Установка необходимых системных утилит

Для установки и настройки всех компонент, необходимых для работы GitLab, нам понадобятся: утилита sudo, набор библиотек для компиляции Ruby, актуальная версия Git и почтовый сервер.

Перед установкой каких-либо пакетов через утилиту apt-get, следует обновить список источников и существущие пакеты, выполнив в консоли такие команды:

apt-get update -y
apt-get upgrade -y

1 2	apt-get update -y apt-get upgrade -y

Здесь и далее команды нужно выполнять от имени пользователя root.

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

apt-get install sudo -y

1	apt-get install sudo -y

Теперь установим библиотеки для компиляции Ruby:

sudo apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libreadline-dev libncurses5-dev libffi-dev curl openssh-server redis-server checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libicu-dev logrotate

1	sudo apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libreadline-dev libncurses5-dev libffi-dev curl openssh-server redis-server checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libicu-dev logrotate

Убедитесь, что на сервере установлен git, и его версия не ниже 1.7.10:

sudo apt-get install -y git-core
git --version

1 2	sudo apt-get install -y git-core git --version

Если установлена устаревшая версия, нужно удалить ее:

sudo apt-get remove git-core

1	sudo apt-get remove git-core

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

# Устанавливаем библиотеки, необходимые для компиляции
sudo apt-get install -y libcurl4-openssl-dev libexpat1-dev gettext libz-dev libssl-dev build-essential

# Загружаем и компилируем исходники
cd /tmp
curl --progress https://git-core.googlecode.com/files/git-1.9.0.tar.gz | tar xz
cd git-1.9.0/
make prefix=/usr/local all
sudo make prefix=/usr/local install

# Устанавливаем библиотеки, необходимые для компиляции

sudo apt-get install -y libcurl4-openssl-dev libexpat1-dev gettext libz-dev libssl-dev build-essential

# Загружаем и компилируем исходники

cd /tmp

curl --progress https://git-core.googlecode.com/files/git-1.9.0.tar.gz | tar xz

cd git-1.9.0/

make prefix=/usr/local all

sudo make prefix=/usr/local install

Обратите внимание на версию git. На момент написания это версия 1.9.0. Уточнить, какая версия git является актуальной, можно на официальной странице проекта.

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

sudo apt-get install -y postfix

1	sudo apt-get install -y postfix

В процессе установки почтовый сервер попросит себя сконфигурировать. Для этого нужно выбрать на появившемся экране пункт «Internet Site» и указать правильное имя хоста — IP-адрес или доменное имя.

Установка Ruby

Для работы GitLab требуется Ruby 2.1.6. Если у вас уже установлен Ruby 1.8, его необходимо удалить перед установкой новой версии:

sudo apt-get remove ruby1.8

1	sudo apt-get remove ruby1.8

Теперь скачаем и скомпилируем Ruby 2.1.6:

mkdir /tmp/ruby && cd /tmp/ruby
curl -L --progress http://cache.ruby-lang.org/pub/ruby/2.1/ruby-2.1.6.tar.gz | tar xz
cd ruby-2.1.6
./configure --disable-install-rdoc
make
sudo make install

mkdir /tmp/ruby && cd /tmp/ruby

curl -L --progress http://cache.ruby-lang.org/pub/ruby/2.1/ruby-2.1.6.tar.gz | tar xz

cd ruby-2.1.6

./configure --disable-install-rdoc

make

sudo make install

Помимо самого Ruby нам понадобится библиотека bundler:

sudo gem install bundler --no-ri --no-rdoc

1	sudo gem install bundler --no-ri --no-rdoc

Создание пользователя для SSH-подключений к GitLab

Создадим для SSH-подключений пользователя git:

sudo adduser --disabled-login --gecos 'GitLab' git

1	sudo adduser --disabled-login --gecos 'GitLab' git

Установка и настройка GitLab Shell

GitLab Shell — это отдельная утилита для управления SSH-доступом и репозиториями. Для ее установки необходимо выполнить следущие команды:

# Переходим в домашнюю директорию
cd /home/git

# Загружаем исходный код
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-shell.git -b v1.9.3
cd gitlab-shell

# Создаем конфигурационный файл
sudo -u git -H cp config.yml.example config.yml

# Переходим в домашнюю директорию

cd /home/git

# Загружаем исходный код

sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-shell.git -b v1.9.3

cd gitlab-shell

# Создаем конфигурационный файл

sudo -u git -H cp config.yml.example config.yml

После выполнения команд нужно отредактировать файл config.yml. В нем в настройке gitlab_url нужно указать будущий адрес GitLab, например:

gitlab_url: http://gitlab.example.com/"

1	gitlab_url: http://gitlab.example.com/"

Теперь устанавливаем и инициализируем утилиту:

sudo -u git -H ./bin/install

1	sudo -u git -H ./bin/install

Установка и настройка базы данных

Для работы GitLab требует базу данных. Разработчики GitLab рекомендуют использовать PostgreSQL, однако поддержка MySQL также присутствует. Для установки PostgreSQL, выполните:

sudo apt-get install -y postgresql-9.1 postgresql-client libpq-dev

1	sudo apt-get install -y postgresql-9.1 postgresql-client libpq-dev

Для установки MySQL:

sudo apt-get install -y mysql-server mysql-client libmysqlclient-dev
sudo mysql_secure_installation

1 2	sudo apt-get install -y mysql-server mysql-client libmysqlclient-dev sudo mysql_secure_installation

Во время установки необходимо будет придумать и ввести пароль root пользователя MySQL.

Теперь нужно создать саму базу данных для работы GitLab. Для этого нужно выполнить несколько SQL-запросов. Начнем с PostgreSQL. В командной строке это делается так:

# Логинимся в PostgreSQL
sudo -u postgres psql -d template1

# Создаем пользователя для GitLab
template1=# CREATE USER git;

# Создаем базу данных для GitLab и даем доступ к ней созданному пользователю
template1=# CREATE DATABASE gitlabhq_production OWNER git;

# Выходим из PostgreSQL
template1=# \q

# Логинимся в PostgreSQL

sudo -u postgres psql -d template1

# Создаем пользователя для GitLab

template1=# CREATE USER git;

# Создаем базу данных для GitLab и даем доступ к ней созданному пользователю

template1=# CREATE DATABASE gitlabhq_production OWNER git;

# Выходим из PostgreSQL

template1=# \q

Теперь MySQL (не забудьте вместо $password поставить хороший, крепкий пароль):

# Логинимся в MySQL
mysql -u root -p

# Тут нужно будет ввести пароль root пользователя MySQL

# Создаем пользователя для GitLab
# вводить 'mysql>' не нужно, он показан для наглядности процесса
# и не забудьте в следущей команде заменить $password на настоящий пароль!
mysql> CREATE USER 'git'@'localhost' IDENTIFIED BY '$password';

# Устанавливаем тип базы данных
mysql> SET storage_engine=INNODB;

# Создаем базу данных для GitLab
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;

# Даем доступ к созданной базе данных пользователю GitLab
mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO 'git'@'localhost';

# Выходим из MySQL
mysql> \q

# Логинимся в MySQL

mysql -u root -p

# Тут нужно будет ввести пароль root пользователя MySQL

# Создаем пользователя для GitLab

# вводить 'mysql>' не нужно, он показан для наглядности процесса

# и не забудьте в следущей команде заменить $password на настоящий пароль!

mysql> CREATE USER 'git'@'localhost' IDENTIFIED BY '$password';

# Устанавливаем тип базы данных

mysql> SET storage_engine=INNODB;

# Создаем базу данных для GitLab

mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;

# Даем доступ к созданной базе данных пользователю GitLab

mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO 'git'@'localhost';

# Выходим из MySQL

mysql> \q

Установка и настройка самого GitLab

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

# Переходим в домашнюю директорию
cd /home/git

# Загружаем GitLab
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 6-8-stable gitlab

# Переходим в домашнюю директорию

cd /home/git

# Загружаем GitLab

sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 6-8-stable gitlab

Обратите внимание на флаг -b 6-8-stable во второй команде. На момент написания этой статьи актуальным является GitLab версии 6.8. Однако рекомендую перед установкой уточнить эту информацию на официальном сайте проекта и подставить в эту команду правильную версию. Кроме того, вместе с GitLab периодически обновляется и GitLab Shell, это также нужно учесть.

Второй шаг — развертывание и настройка. Сюда входят создание необходимых файлов конфигурации, создание необходимых приложению папок и установка прав доступа на уже существующие папки:

# Переходим в папку GitLab
cd /home/git/gitlab

# Создаем файл конфигурации для GitLab
sudo -u git -H cp config/gitlab.yml.example config/gitlab.yml

# Выставляем владельца и права на папки log/ и tmp/
sudo chown -R git log/
sudo chown -R git tmp/
sudo chmod -R u+rwX log/
sudo chmod -R u+rwX tmp/

# Создаем папку для сателлитов и выставляем на нее права
sudo -u git -H mkdir /home/git/gitlab-satellites
sudo chmod u+rwx,g+rx,o-rwx /home/git/gitlab-satellites

# Выставляем права на папки tmp/pids/ и tmp/sockets/
sudo chmod -R u+rwX tmp/pids/
sudo chmod -R u+rwX tmp/sockets/

# Выставляем праав на папку public/uploads/
sudo chmod -R u+rwX  public/uploads

# Создаем файл конфигурации для сервера Unicorn
sudo -u git -H cp config/unicorn.rb.example config/unicorn.rb

# Создаем файл конфигурации для Rack attack
sudo -u git -H cp config/initializers/rack_attack.rb.example config/initializers/rack_attack.rb

# Переходим в папку GitLab

cd /home/git/gitlab

# Создаем файл конфигурации для GitLab

sudo -u git -H cp config/gitlab.yml.example config/gitlab.yml

# Выставляем владельца и права на папки log/ и tmp/

sudo chown -R git log/

sudo chown -R git tmp/

sudo chmod -R u+rwX log/

sudo chmod -R u+rwX tmp/

# Создаем папку для сателлитов и выставляем на нее права

sudo -u git -H mkdir /home/git/gitlab-satellites

sudo chmod u+rwx,g+rx,o-rwx /home/git/gitlab-satellites

# Выставляем права на папки tmp/pids/ и tmp/sockets/

sudo chmod -R u+rwX tmp/pids/

sudo chmod -R u+rwX tmp/sockets/

# Выставляем праав на папку public/uploads/

sudo chmod -R u+rwX public/uploads

# Создаем файл конфигурации для сервера Unicorn

sudo -u git -H cp config/unicorn.rb.example config/unicorn.rb

# Создаем файл конфигурации для Rack attack

sudo -u git -H cp config/initializers/rack_attack.rb.example config/initializers/rack_attack.rb

После выполнения команд нужно отредактировать файл config/gitlab.yml. В нем нужно указать следующие настройки:

Настройка	Раздел	Описание	Пример
`host`	`gitlab`	Cюда надо вписать адрес, по которому будет доступен GitLab	`gitlab.example.com`
`email_from`	`gitlab`	Тут нужно прописать email, с которого будет отправляться почта	`gitlab@example.com`
`support_emal`	`gitlab`	Адрес тех. поддержки. Если его закомментировать, будет использован адрес из `email_from`	`support@example.com`
`bin_path`	`git`	Установите значение `/usr/local/bin/git`, если компилировали git вручную на первом этапе установки	`/usr/local/bin/git`

E-mail адрес из email_from также нужно установить в конфигурации git:

sudo -u git -H git config --global user.name "GitLab"
sudo -u git -H git config --global user.email "gitlab@example.com"
sudo -u git -H git config --global core.autocrlf input

sudo -u git -H git config --global user.name "GitLab"

sudo -u git -H git config --global user.email "gitlab@example.com"

sudo -u git -H git config --global core.autocrlf input

Теперь нужно сконфигурировать базу данных. Для PostgreSQL:

sudo -u git cp config/database.yml.postgresql config/database.yml
sudo -u git -H chmod o-rwx config/database.yml

1 2	sudo -u git cp config/database.yml.postgresql config/database.yml sudo -u git -H chmod o-rwx config/database.yml

Для MySQL:

sudo -u git cp config/database.yml.mysql config/database.yml
sudo -u git -H chmod o-rwx config/database.yml

1 2	sudo -u git cp config/database.yml.mysql config/database.yml sudo -u git -H chmod o-rwx config/database.yml

Не забудьте указать в файле config/database.yml логин и пароль для доступа к вашей базе данных. Следущий шаг — установка зависимостей. Делается это одной простой командой. Если вы используете PostgreSQL:

cd /home/git/gitlab
sudo -u git -H bundle install --deployment --without development test mysql aws

1 2	cd /home/git/gitlab sudo -u git -H bundle install --deployment --without development test mysql aws

Если используете MySQL:

cd /home/git/gitlab
sudo -u git -H bundle install --deployment --without development test postgres aws

1 2	cd /home/git/gitlab sudo -u git -H bundle install --deployment --without development test postgres aws

Теперь нужно инициализировать приложение. Сюда входят инициализация базы данных и установка ротации логов:

sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production

# Тут нужно будет ввести yes для подтверждения создания таблиц в базе данных

# Создаем инициализационный скрипт
sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab

# Добавляем GitLab в местный авторан
sudo update-rc.d gitlab defaults 21

# Создаем ротатор логов
sudo cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab

sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production

# Тут нужно будет ввести yes для подтверждения создания таблиц в базе данных

# Создаем инициализационный скрипт

sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab

# Добавляем GitLab в местный авторан

sudo update-rc.d gitlab defaults 21

# Создаем ротатор логов

sudo cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab

Теперь осталось проверить статус приложения и запустить его. Проверяется статус такой командой:

sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production

1	sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production

Корректно установленное приложение должно выдавать примерно следущее:

Страница файлов проекта в GitLab

Если все хорошо — приложение можно запускать:

sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production
sudo service gitlab start

1 2	sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production sudo service gitlab start

Установка и настройка Nginx

Последний этап установки GitLab — установка и настройка сервера Nginx. Установка выглядит так:

sudo apt-get install -y nginx

1	sudo apt-get install -y nginx

Копируем конфигурационный файл Nginx из дистрибутива GitLab:

sudo cp lib/support/nginx/gitlab /etc/nginx/sites-available/gitlab
sudo ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab

1 2	sudo cp lib/support/nginx/gitlab /etc/nginx/sites-available/gitlab sudo ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab

Не забудьте указать правильный адрес вашего GitLab в файле /etc/nginx/sites-available/gitlab в настройке server_name раздела server. Мне также пришлось указать IP-адрес сервера в настройке listen раздела server. Теперь нужно перезапустить сервер:

sudo service nginx restart

1	sudo service nginx restart

Готово! Установка и настройка GitLab окончена. Убедитесь, что все правильно настроено, выполнив команду:

sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production

1	sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production

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

Логин:  root
Пароль: 5iveL!fe

1 2	Логин: root Пароль: 5iveL!fe

Не забудьте сменить пароль после авторизации! Приятной работы!

P.S. Еще более подробно написано о настройке gitlab в статье: https://www.linode.com/docs/applications/development/how-to-install-and-configure-gitlab-on-ubuntu-14-04-trusty-tahr

Источник: http://popel-studio.com/blog/article/sobstvenniy-hosting-repozitoriev-s-pomoshyu-gitlab.html

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Управление торговлей, Бухгалтерия

Posted on 30.10.2015 by rudjuk Leave a comment

Диалог позволяет осуществлять групповое проведение документов и восстановление последовательностей проведения документов.

Открываем «1С:Підприємство» (в режиме предприятия) – Операции – Проведение документов.

Проведение документов

На закладке «Проведение документов» осуществляется проведение выбранных документов в указанном интервале. Если Вы хотите чтобы какой – либо документ участвовал в проведение необходимо правой клавишей мыши поставить пометку слева от наименований таких документов.

В нижней части закладки «Проведение документов» задается интервал дат, в котором будут проводиться выбранные Нами документы. Для установки интервала следует ввести начальную и конечную дату, см. рис. представленный ниже:

При необходимости проведения документов без ограничения по дате, необходимо установить флажок «Не ограничивать«

Также необходимо выбрать какие именно документы будут участвовать в проведении:
·        Проведенные
·        Непроведенные
·        Проведенные и непроведенные

После установки всех необходимых параметров для выполнения проведения документов следует нажать кнопку «Выполнить».
Если проведение прошло успешно, будет выдано сообщение «Проведение документов завершено!».

Если Вы хотите выйти из режима проведения документов необходимо нажать на кнопку «Закрыть».

Восстановление последовательности

На закладке «Восстановление последовательности» осуществляется восстановление последовательности проведения документов.

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

В графе «Актуальна» для каждой последовательности выводится текущая позиция границы последовательности.

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

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

Источник: http://esodin.by/main/smallbusiness/Enterprise_8/untitled10.php?option=com_content&task=view&id=108&catid=24

Автоматизация предприятия

Решение проблемы «Too many open files» в MySQL

Posted on 28.10.2015 by rudjuk Leave a comment

При росте количества таблиц и баз данных в MySQL рано или поздно Вы получите ошибку: Too many open files. Данная ошибка связана с не достаточным количеством выделенных дескрипторов файлов, на уровне операционной системы или MySQL.

Анализ дескрипторов Вы можете произвести командой:

ulimit -a

ulimit -a

В результате увидите нечто подобное:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 257403
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 257403
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

core file size (blocks, -c) 0

data seg size (kbytes, -d) unlimited

scheduling priority (-e) 0

file size (blocks, -f) unlimited

pending signals (-i) 257403

max locked memory (kbytes, -l) 32

max memory size (kbytes, -m) unlimited

open files (-n) 1024

pipe size (512 bytes, -p) 8

POSIX message queues (bytes, -q) 819200

real-time priority (-r) 0

stack size (kbytes, -s) 10240

cpu time (seconds, -t) unlimited

max user processes (-u) 257403

virtual memory (kbytes, -v) unlimited

file locks (-x) unlimited

Как видите, в данном случае выдалось 1024 открытых файлов. Это не большое количество и может Вас не устроить.

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

ulimit -n

ulimit -n

Так же, еще вариант просмотра:

ulimit -Hn
ulimit -Sn

1 2	ulimit -Hn ulimit -Sn

Количество выделенных дескрипторов пользователю mySQL:

su mysql 
ulimit -a

1 2	su mysql ulimit -a

Для Debian и Linux Ubuntu:

su mysql -s /bin/sh -c "ulimit -a"

1	su mysql -s /bin/sh -c "ulimit -a"

Увеличиваем количество дескипторов

vi /etc/security/limits.conf

1	vi /etc/security/limits.conf

Заполняем таким содержимым:

* soft nofile 1024000
* hard nofile 1024000
* soft nproc 10240
* hard nproc 10240

* soft nofile 1024000

* hard nofile 1024000

* soft nproc 10240

* hard nproc 10240

Установка параметров, специфичных для MySQL:

mysql hard nofile 1024000
mysql soft nofile 1024000

1 2	mysql hard nofile 1024000 mysql soft nofile 1024000

Отредактируем файл /etc/security/limits.d/90-nproc.conf:

vi /etc/security/limits.d/90-nproc.conf

1	vi /etc/security/limits.d/90-nproc.conf

Заполним файл:

* soft nofile 1024000
* hard nofile 1024000
* soft nproc 10240
* hard nproc 10240
root soft nproc unlimited

* soft nofile 1024000

* hard nofile 1024000

* soft nproc 10240

* hard nproc 10240

root soft nproc unlimited

Установите под root:

ulimit -Hn 1024000

1	ulimit -Hn 1024000

Теперь, перезагрузите сервер и поменяйте параметры в конфиге MySQL:

vi /etc/my.cnf

1	vi /etc/my.cnf

Запишите после [mysqld]:

[mysqld]
open_files_limit = 1024000

1 2	[mysqld] open_files_limit = 1024000

Запишите после [mysqld_safe]:

[mysqld_safe]
open_files_limit = 1024000

1 2	[mysqld_safe] open_files_limit = 1024000

Теперь перезагрузите сервер:

service mysqld restart

1	service mysqld restart

Для проверки настроек в MySQL войдите:

mysql -u root -p

1	mysql -u root -p

Выполните команду:

show global variables like 'open%';

1	show global variables like 'open%';

В результате, должны увидеть:

+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| open_files_limit | 1024000 |
+------------------+--------+
1 row in set (0.00 sec)

+------------------+--------+

| Variable_name | Value |

+------------------+--------+

| open_files_limit | 1024000 |

+------------------+--------+

1 row in set (0.00 sec)

Перезагрузите сервер и проверьте, сохранились ли настройки:

mysql -u root -p
show global variables like 'open%';

1 2	mysql -u root -p show global variables like 'open%';

Если после загрузки Вы увидите значение 1024, то не сохранились настройки. В таком случае, читайте решение проблем.

Решение проблем

Проверьте файл /etc/security/limits.conf он должен содержать:

* hard nofile 102400
* soft nofile 102400

1 2	* hard nofile 102400 * soft nofile 102400

Или установите лимит таким образом:

ulimit -Hn 102400

1	ulimit -Hn 102400

Перезагрузите MySQL:

service mysqld restart

1	service mysqld restart

Можно внести изменения в:

vi /etc/init.d/mysqld

1	vi /etc/init.d/mysqld

Добавьте следующее:

ulimit -S -n ${DAEMON_FILES_LIMIT:-102400} >/dev/null 2>&1

1	ulimit -S -n ${DAEMON_FILES_LIMIT:-102400} >/dev/null 2>&1

В настройках /etc/my.cnf укажите:

[myqld_safe]
open_files_limit = 102400

1 2	[myqld_safe] open_files_limit = 102400

или

[myqld]
open_files_limit = 102400

1 2	[myqld] open_files_limit = 102400

Проблемы в Linux Ubuntu 15.04

Все перечисленные вещи не помогли в Linux Ubuntu 15.04. Немного погуглив, я нашел решение для Linux Ubuntu 15.04.

Нужно внести изменения в файл: /lib/systemd/system/mysql.service

К содержимому данного файла:

[Unit]
Description=MySQL Community Server
After=network.target
After=syslog.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service

[Service]
User=mysql
Group=mysql
PermissionsStartOnly=true
ExecStartPre=/usr/share/mysql/mysql-systemd-start pre
ExecStart=/usr/bin/mysqld_safe
ExecStartPost=/usr/share/mysql/mysql-systemd-start post
TimeoutSec=600
Restart=on-failure

[Unit]

Description=MySQL Community Server

After=network.target

After=syslog.target

[Install]

WantedBy=multi-user.target

Alias=mysql.service

[Service]

User=mysql

Group=mysql

PermissionsStartOnly=true

ExecStartPre=/usr/share/mysql/mysql-systemd-start pre

ExecStart=/usr/bin/mysqld_safe

ExecStartPost=/usr/share/mysql/mysql-systemd-start post

TimeoutSec=600

Restart=on-failure

Добавьте:

LimitNOFILE = infinity
LimitMEMLOCK = infinity

1 2	LimitNOFILE = infinity LimitMEMLOCK = infinity

MySQL

Проблема доступности для продажи товара в Shop-Script

Posted on 24.10.2015 by rudjuk Leave a comment

Столкнулся с проблемой заказа товаров, которые импортировал через Яндекс xml в интернет-магазин Shop Script.

shop-script

Как видно из скриншота, выдается сообщение, что товар временно нельзя купить. Не помогает ни изменение количества товара, ни привязка к товару.

В результате, нашел причину, что такое пишется, когда sku.avable не равен нулю.

Поэтому, зашел в базу и SQL-запросом поправил данную ситуацию:

UPDATE shop_product_skus
SET available=1

1 2	UPDATE shop_product_skus SET available=1

Как вывести блог на отдельной странице WordPress. 2 способа

Posted on 18.10.2015 by rudjuk Leave a comment

Я видел много сайтов на WordPress, у которых на главной странице отображается какая-нибудь статичная страница, а страница блога находится отдельно, например yourwebsite.com/blog.

Как же это реализовать на своём собственной сайте? На самом деле существует два способа – один простой и один не очень, рассмотрим их оба.

Способ 1. Использование index.php в качестве шаблона блога.

Это стандартный способ, предусмотренный в WordPress. Скорее всего на тех сайтах, про которые я говорил в самом начале поста, используется именно он. Рассмотрим пошагово.

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

Шаг 1. Создание страницы блога.

Ну, что тут сказать, переходим в Страницы > Добавить новую, указываем какой-нибудь заголовок, например Блог и какой-нибудь URL, например blog, после этого сохраняем. Всё, с шагом 1 покончено.

Настройка блога

Шаг 2. Настраиваем отображение страниц в настройках.

Переходим в Параметры > Чтение, настраиваем отображение нужной страницы на главной, а для страницы записей устанавливаем созданную в предыдущем шаге.

WordPress

Шаг 3. Последний шаг. Добавляем страницу в меню.

Уже после завершения второго шага при переходе по адресу блога (у нас это yourwebsite.com/blog), у вас будет отображаться страница с записями, использующая шаблон файла index.php.

Тем не менее можно также добавить эту страницу в меню сайта (если поддерживается темой разумеется). Для этого переходим в Внешний вид > Меню, слева в колонке выбираем нашу страницу блога и нажимаем кнопку «Добавить в меню»

Способ 2. Использование собственного шаблона блога. Создание нескольких блогов на одном сайте WordPress.

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

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

Шаг 1. Создание шаблона страницы

Открываем папку с темой и создаем там файл произвольного названия, например blog-template.php. Внутрь файла вставляем:

<?php
/*
 * Template name: Блог
 */

<?php

* Template name: Блог

Шаг 2. Создаем страницу блога

Этот шаг аналогичен первому шагу из начала поста. Итак, переходим в Страницы > Добавить новую, придумываем название и URL странице, и кроме всего прочего в атрибутах страницы указываем только что созданный нами шаблон.

Блог WordPress

Сохраняем.

Шаг 3. Плагин постраничной навигации

Однозначно, что нам понадобится постраничная навигация. Скорее всего у вас уже используется какой-то плагин или функция навигации. Если же навигация не будет работать, рекомендую поставить WP_PageNavi – этот плагин работает отлично, я его протестировал, всё ок.

Шаг 4. Шаблон страницы блога

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

<?php
/*
 * Template name: Блог
 */
$current_page = (get_query_var('paged')) ? get_query_var('paged') : 1; // определяем текущую страницу блога
$args = array(
	'posts_per_page' => get_option('posts_per_page'), // значение по умолчанию берётся из настроек, но вы можете использовать и собственное
	'paged'          => $current_page // текущая страница
);
query_posts( $args );
 
$wp_query->is_archive = true;
$wp_query->is_home = false;
 
while(have_posts()): the_post();
	?>
	<h2><?php the_title() /* заголовок */ ?></h2>
	<p><?php the_content() /* содержимое поста */ ?></p>
	<?php
endwhile;
 
if( function_exists('wp_pagenavi') ) wp_pagenavi(); // функция постраничной навигации

<?php

* Template name: Блог

$current_page = (get_query_var('paged')) ? get_query_var('paged') : 1; // определяем текущую страницу блога

$args = array(

'posts_per_page' => get_option('posts_per_page'), // значение по умолчанию берётся из настроек, но вы можете использовать и собственное

'paged' => $current_page // текущая страница

);

query_posts( $args );

$wp_query->is_archive = true;

$wp_query->is_home = false;

while(have_posts()): the_post();

<?php

endwhile;

if( function_exists('wp_pagenavi') ) wp_pagenavi(); // функция постраничной навигации

Источник: http://truemisha.ru/blog/wordpress/blog-na-otdelnoy-stranitse.html

Wordpress

Список всех используемых хуков в WordPress

Posted on 18.10.2015 by rudjuk Leave a comment

Чем быстрее грузится сайт, тем лучше! Это всем известный факт.

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

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

В файл functions.php вставляем следующий код:

function list_hooked_functions($tag=false){
 global $wp_filter;
 if ($tag) {
  $hook[$tag]=$wp_filter[$tag];
  if (!is_array($hook[$tag])) {
  trigger_error("Nothing found for '$tag' hook", E_USER_WARNING);
  return;
  }
 }
 else {
  $hook=$wp_filter;
  ksort($hook);
 }
 echo '<pre>';
 foreach($hook as $tag => $priority){
  echo "<br />&gt;&gt;&gt;&gt;&gt;\t<strong>$tag</strong><br />";
  ksort($priority);
  foreach($priority as $priority => $function){
  echo $priority;
  foreach($function as $name => $properties) echo "\t$name<br />";
  }
 }
 echo '</pre>';
 return;
}

function list_hooked_functions($tag=false){

global $wp_filter;

if ($tag) {

$hook[$tag]=$wp_filter[$tag];

if (!is_array($hook[$tag])) {

trigger_error("Nothing found for '$tag' hook", E_USER_WARNING);

return;

}

else {

$hook=$wp_filter;

ksort($hook);

}

echo '<pre>';

foreach($hook as $tag => $priority){

echo "<br />>>>>>\t<strong>$tag</strong><br />";

ksort($priority);

foreach($priority as $priority => $function){

echo $priority;

foreach($function as $name => $properties) echo "\t$name<br />";

}

echo '</pre>';

return;

}

Для вывода списка вставляем ниже приведенный код в том файле, в котором хотим увидеть результат, я вставлял в head.php

<?php list_hooked_functions() ?>

1	<?php list_hooked_functions() ?>

Джерело: http://site-style.by/spisok-vsex-ispolzuemyx-xukov-v-wordpress/

Wordpress

nginx + php-fpm + PHP APC + WordPress multisite (subdirectory) + WP Super

Posted on 14.10.2015 by rudjuk Leave a comment

У меня на хостинге использовался Nginx+Apache. Однако, в один прекрасный момент я столкнулся с тем, что интернет-магазины на WordPress не закидывали в корзину товары. Вначале я думал, что это проблема в CMS, потом, что проблема PHP. Но, в результате, после длительной борьбы с проблемой я увидел, что проблема в Nginx. Просто при ЧПУ нужно исправить настройки. В результате, получилось решение Nginx + PHP-FPM.

Вот настройки /etc/nginx/nginx.conf:

# Generic startup file.
user {user} {group};
worker_processes  3;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

# Keeps the logs free of messages about not being able to bind().
#daemon     off;

events {
	worker_connections  1024;
}

http {
#	rewrite_log on;

	include mime.types;
	default_type       application/octet-stream;
	access_log         /var/log/nginx/access.log;
	sendfile           on;
#	tcp_nopush         on;
	keepalive_timeout  3;
#	tcp_nodelay        on;
#	gzip               on;
	index              index.php index.html index.htm;

	# Upstream to abstract backend connection(s) for PHP.
	upstream php {
#        	server unix:/tmp/php-fpm.sock;
       	     server 127.0.0.1:9000;
	}

	include sites-enabled/*;
}

# Generic startup file.

user {user} {group};

worker_processes 3;

error_log /var/log/nginx/error.log;

pid /var/run/nginx.pid;

# Keeps the logs free of messages about not being able to bind().

#daemon off;

events {

worker_connections 1024;

}

http {

# rewrite_log on;

include mime.types;

default_type application/octet-stream;

access_log /var/log/nginx/access.log;

sendfile on;

# tcp_nopush on;

keepalive_timeout 3;

# tcp_nodelay on;

# gzip on;

index index.php index.html index.htm;

# Upstream to abstract backend connection(s) for PHP.

upstream php {

# server unix:/tmp/php-fpm.sock;

server 127.0.0.1:9000;

}

include sites-enabled/*;

}

Настройка виртуального хостинга:

# WordPress multisite subdirectory rules.
# Designed to be included in any server {} block.

# This order might seem weird - this is attempted to match last if rules below fail.
# http://wiki.nginx.org/HttpCoreModule
location / {
	try_files $uri $uri/ /index.php?$args;
}

# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Directives to send expires headers and turn off 404 error logging.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
	expires 24h;
	log_not_found off;
}

# Pass uploaded files to wp-includes/ms-files.php.
rewrite /files/$ /index.php last;

# For multisite:  Use a caching plugin/script that creates symlinks to the correct subdirectory structure to get some performance gains.
set $cachetest "$document_root/wp-content/cache/ms-filemap/${host}${uri}";
if ($uri ~ /$) {
	set $cachetest "";
}
if (-f $cachetest) {
	# Rewrites the URI and stops rewrite processing so it doesn't start over and attempt to pass it to the next rule.
	rewrite ^ /wp-content/cache/ms-filemap/${host}${uri} break;
}

if ($uri !~ wp-content/plugins) {
	rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last;
}

# Uncomment one of the lines below for the appropriate caching plugin (if used).
# include global/wordpress-ms-subdir-wp-super-cache.conf;
# include global/wordpress-ms-subdir-w3-total-cache.conf;

# Rewrite multisite '.../wp-.*' and '.../*.php'.
if (!-e $request_filename) {
	rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;
	rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;
}

# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
	# Zero-day exploit defense.
	# http://forum.nginx.org/read.php?2,88845,page=3
	# Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.
	# Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine.  And then cross your fingers that you won't get hacked.
	try_files $uri =404;

	fastcgi_split_path_info ^(.+\.php)(/.+)$;
	include fastcgi_params;
	fastcgi_index index.php;
	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#	fastcgi_intercept_errors on;
	fastcgi_pass php;
}

# WordPress multisite subdirectory rules.

# Designed to be included in any server {} block.

# This order might seem weird - this is attempted to match last if rules below fail.

# http://wiki.nginx.org/HttpCoreModule

location / {

try_files $uri $uri/ /index.php?$args;

}

# Add trailing slash to */wp-admin requests.

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Directives to send expires headers and turn off 404 error logging.

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {

expires 24h;

log_not_found off;

}

# Pass uploaded files to wp-includes/ms-files.php.

rewrite /files/$ /index.php last;

# For multisite: Use a caching plugin/script that creates symlinks to the correct subdirectory structure to get some performance gains.

set $cachetest "$document_root/wp-content/cache/ms-filemap/${host}${uri}";

if ($uri ~ /$) {

set $cachetest "";

}

if (-f $cachetest) {

# Rewrites the URI and stops rewrite processing so it doesn't start over and attempt to pass it to the next rule.

rewrite ^ /wp-content/cache/ms-filemap/${host}${uri} break;

}

if ($uri !~ wp-content/plugins) {

rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last;

}

# Uncomment one of the lines below for the appropriate caching plugin (if used).

# include global/wordpress-ms-subdir-wp-super-cache.conf;

# include global/wordpress-ms-subdir-w3-total-cache.conf;

# Rewrite multisite '.../wp-.*' and '.../*.php'.

if (!-e $request_filename) {

rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;

rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;

}

# Pass all .php files onto a php-fpm/php-fcgi server.

location ~ \.php$ {

# Zero-day exploit defense.

# http://forum.nginx.org/read.php?2,88845,page=3

# Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.

# Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine. And then cross your fingers that you won't get hacked.

try_files $uri =404;

fastcgi_split_path_info ^(.+\.php)(/.+)$;

include fastcgi_params;

fastcgi_index index.php;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

# fastcgi_intercept_errors on;

fastcgi_pass php;

}

Для WP Super Cache:

# WP Super Cache rules.
# Designed to be included from a 'wordpress-ms-...' configuration file.

# Enable detection of the .gz extension for statically compressed content.
# Comment out this line if static gzip support is not compiled into nginx.
gzip_static on;

set $supercacheuri "";
set $supercachefile "$document_root/wp-content/cache/supercache/${http_host}${uri}index.html";
if (-e $supercachefile) {
	set $supercacheuri "/wp-content/cache/supercache/${http_host}${uri}index.html";
}

# If this is a POST request, pass the request onto WordPress.
if ($request_method = POST) {
	set $supercacheuri "";
}

# If there is a query string, serve the uncached version.
if ($query_string) {
	set $supercacheuri "";
}

# Logged in users and those who have posted a comment get the non-cached version.
if ($http_cookie ~* comment_author_|wordpress_logged_in|wp-postpass_) {
	set $supercacheuri "";
}

# Mobile browsers get the non-cached version.
# Wastes CPU cycles if there isn't a mobile browser WP theme for the site.
if ($http_x_wap_profile) {
	set $supercacheuri "";
}

if ($http_profile) {
	set $supercacheuri "";
}

if ($http_user_agent ~* (2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800)) {
	set $supercacheuri "";
}

if ($http_user_agent ~* (w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-)) {
	set $supercacheuri "";
}

# Stop processing if the supercache file is valid.
if ($supercacheuri) {
	rewrite ^ $supercacheuri break;
}

# WP Super Cache rules.

# Designed to be included from a 'wordpress-ms-...' configuration file.

# Enable detection of the .gz extension for statically compressed content.

# Comment out this line if static gzip support is not compiled into nginx.

gzip_static on;

set $supercacheuri "";

set $supercachefile "$document_root/wp-content/cache/supercache/${http_host}${uri}index.html";

if (-e $supercachefile) {

set $supercacheuri "/wp-content/cache/supercache/${http_host}${uri}index.html";

}

# If this is a POST request, pass the request onto WordPress.

if ($request_method = POST) {

set $supercacheuri "";

}

# If there is a query string, serve the uncached version.

if ($query_string) {

set $supercacheuri "";

}

# Logged in users and those who have posted a comment get the non-cached version.

if ($http_cookie ~* comment_author_|wordpress_logged_in|wp-postpass_) {

set $supercacheuri "";

}

# Mobile browsers get the non-cached version.

# Wastes CPU cycles if there isn't a mobile browser WP theme for the site.

if ($http_x_wap_profile) {

set $supercacheuri "";

}

if ($http_profile) {

set $supercacheuri "";

}

if ($http_user_agent ~* (2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800)) {

set $supercacheuri "";

}

if ($http_user_agent ~* (w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-)) {

set $supercacheuri "";

}

# Stop processing if the supercache file is valid.

if ($supercacheuri) {

rewrite ^ $supercacheuri break;

}

Источник: https://wordpress.org/support/topic/nginx-php-fpm-php-apc-wordpress-multisite-subdirectory-wp-super-cache

Сессии. Подробное описание работы и объяснение механизма

Posted on 13.10.2015 by rudjuk Leave a comment

Введение
Как устроены, и как работают сессии?
Область применения.
Возможные проблемы и их устранение.
Безопасность
Дополнительная информация:
Пример авторизации с помощью сессий
ОПС! Очень Полезные Ссылки:
Comments

Введение
Сессии — это на самом деле очень просто.
Надо только понимать, для чего они нужны и как устроены.
Ответим сначала на первый вопрос.
Как показано в соответствующем разделе этого FAQ, веб-сервер не поддерживает постоянного соединения с клиентом, и каждый запрос обрабатывается, как новый, безо всякой связи с предыдущими.
То есть, нельзя ни отследить запросы от одного и того же посетителя, ни сохранить для него переменные между просмотрами отдельных страниц. Вот для решения этих двух задач и были изобретены сессии.
Собственно, сессии, если в двух словах — это механизм, позволяющий однозначно идентифицировать браузер и создающий для этого браузера файл на сервере, в котором хранятся переменные сеанса.

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

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

Как устроены, и как работают сессии?
Для начала надо как-то идентифицировать браузер. Для этого надо выдать ему уникальный идентификатор и попросить передавать его с каждым запросом. Стыдно признаться, но когда я впервые узнал о сессиях, я думал, что это какой-то особый механизм, некий новый способ общения браузера с сервером — «сессии». Что идентификатор сессии передается каким-то особым образом. Разочарование было жестоким.
Сессии используют стандартные, хорошо известные способы передачи данных. Собственно, других-то просто и нет.
Идентификатор — это обычная переменная. По умолчанию ее имя — PHPSESSID.
Задача PHP отправить ее браузеру, чтобы тот вернул ее со следующим запросом. Из уже упоминавшегося раздела FAQ ясно, что переменную можно передать только двумя способами: в куках или POST/GET запросом.
PHP использует оба варианта.
За это отвечают две настройки в php.ini:
session.use_cookies — если равно 1, то PHP передает идентификатор в куках, если 0 — то нет.
session.use_trans_sid если равно 1, то PHP передает его, добавляя к URL и формам, если 0 — то нет.
Менять эти и другие параметры сессий можно так же, как и другие настройки PHP — в файле php.ini, а так же с помощью команды ini_set() или в файлах настройки веб-сервера

Если включена только первая, то при старте сессии (при каждом вызове session_start()) клиенту устанавливается кука. Браузер исправно при каждом следующем запросе эту куку возвращает и PHP имеет идентификатор сессии. Проблемы начинаются, если браузер куки не возвращает. В этом случае, не получая куки с идентификатором, PHP будет все время стартовать новую сессию, и механизм работать не будет.

Если включена только вторая, то кука не выставляется. А происходит то, ради чего, в основном, собственно, и стоит использовать встроенный механизм сессий. После того, как скрипт выполняет свою работу, и страница полностью сформирована, PHP просматривает ее всю и дописывает к каждой ссылке и к каждой форме передачу идентификатора сессии. Это выглядит примерно так:
<a href="/index.php">Index</a> превращается в
<a href="/index.php?PHPSESSID=9ebca8bd62c830d3e79272b4f585ff8f">Index</a>
а к формам добавляется скрытое поле
<input type="hidden" name="PHPSESSID" value="00196c1c1a02e4c37ac04f921f4a5eec" />
И браузер при клике на любую ссылку, или при нажатии на кнопку в форме, пошлет в запросе нужную нам переменную — идентификатор сессии!
По очевидным причинам идентификатор добавляется только к относительным ссылкам.

Теоретически, в наших с вами самодельных сессиях на куках и базе, можно самому, руками приписать ко всем ссылками передачу ид — и тогда наши собственные сессии будут работать независимо от кук. Но, согласитесь — приятнее, когда эту работу делает кто-то другой? 😉

По умолчанию в последних версиях PHP включены обе опции. Как PHP поступает в этом случае? Кука выставляется всегда. А ссылки автодополняются только если РНР не обнаружил куку с идентификатором сессии. Когда пользователь в првый раз за этот сеанс заходит на сайт, ему ставится кука, и дополняются ссылки. При следующем запросе, если куки поддерживаются, PHP видит куку и перестает дополнять ссылки. Если куки не работают, то PHP продолжает исправно добавлять ид к ссылкам, и сессия не теряется.
Пользователи, у которых работают куки, увидят длинную ссылку с ид только один раз.

Фух. С передачей идентификатора закончили.
Теперь осталось привязать к нему файл с данными на стороне сервера.
PHP это сделает за нас. Достаточно просто написать

session_start();
$_SESSION['test']='Hello world!';

1 2	session_start(); $_SESSION['test']='Hello world!';

И PHP запишет в файл, связанный с этой сессией, переменную test.
Здесь очень важное замечание.
Массив $_SESSION — особенный.
В нем, собственно, и находятся переменные, которые мы ходим сделать доступными в различных скриптах.
Чтобы поместить переменную в сессию, достаточно присвоить ее элементу массива $_SESSION.
Чтобы получить ее значение — достаточно обратиться к тому же элементу. Пример будет чуть ниже.

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

<? 
session_start(); 
if (!isset($_SESSION['counter'])) $_SESSION['counter']=0;
echo "Вы обновили эту страницу ".$_SESSION['counter']++." раз. ";
echo "<br><a href=".$_SERVER['PHP_SELF'].">обновить"; 
?>

session_start();

if (!isset($_SESSION['counter'])) $_SESSION['counter']=0;

echo "Вы обновили эту страницу ".$_SESSION['counter']++." раз. ";

echo "<br><a href=".$_SERVER['PHP_SELF'].">обновить";

Мы проверяем, есть ли у нас в сессии переменная counter, если нет, то создаем ее со значением 0, а дальше выводим ее значение и увеличиваем на единицу. Увеличенное значение запишется в сессию, и при следующем вызове скрипта переменная будет иметь значение 1, и так далее.
Все очень просто.

Для того, чтобы иметь доступ к переменным сессии на любых страницах сайта, надо написать ТОЛЬКО ОДНУ(!) строчку в самом начале КАЖДОГО файла, в котором нам нужны сессии:

session_start();

1	session_start();

И далее обращаться к элементам массива $_SESSION. Например, проверка авторизации будет выглядеть примерно так:

session_start();
if ($_SESSION['authorized']<>1) {
header("Location: /auth.php");
exit;
}

session_start();

if ($_SESSION['authorized']<>1) {

header("Location: /auth.php");

exit;

}

Удаление переменных из сессии.
Если у вас register_globals=off, то достаточно написать

unset($_SESSION['var']);

1	unset($_SESSION['var']);

Если же нет, то тогда рядом с ней надо написать

session_unregister('var');

1	session_unregister('var');

Область применения.
Очень важно понимать, для чего сессии стоит использовать, а для чего — нет.

Во-первых, помните, что сессии можно применять только тогда, когда они нужны самому пользователю, а не для того, чтобы чинить ему препятствия. Ведь он в любой момент может избавиться от идентификатора!
Скажем, при проверке на то, что заполняет форму человек, а не скрипт, пользователь сам заинтересован в том, чтобы сессия работала — иначе он не сможет отправить форму! А вот для ограничения количества запросов к скрипту сессия уже не годится — злонамеренный скрипт просто не будет возвращать идентификатор.

Во-вторых. Важно четко себе представлять тот факт, что сессия — это сеанс работы с сайтом, так как его понимает человек. Пришел, поработал, закрыл браузер — сессия завершилась. Как сеанс в кино. Хочешь посмотреть еще один – покупай новый билет. Стартуй новый сеанс. Этому есть и техническое объяснение. Гарантированно механизм сессий работает только именно до закрытия браузера. Ведь у клиента могут не работать куки, а в этом случае, естественно, все дополненные идентификатором ссылки пропадут с его закрытием.
Правда, сессия может пропасть и без закрытия браузера. В силу ограничений, рассмотренных в самом главном разделе этого FAQ, механизм сессий не может определить тот момент, когда пользователь закрыл браузер. Для этого используется таймаут – заранее определенное время, по истечении которого мы считаем, что пользователь ушел с сайта. По умолчанию этот параметр равен 24 минутам.
Если вы хотите сохранять пользовательскую информацию на более длительный срок, то используйте куки и, если надо — базу данных на сервере. В частности, именно так работают все популярные системы авторизации:
— по факту идентификации пользователя стартует сессия и признак авторизованности передается в ней.
— Если надо «запомнить» пользователя, то ему ставится кука, его идентифицирующая.
— При следующем заходе пользователя на сайт, для того, чтобы авторизоваться, он должен либо ввести пароль, либо система сама его опознает по поставленной ранее куке, и стартует сессию. Новую сессию, а не продолжая старую.

В-третьих, не стоит стартовать сессии без разбору, каждому входящему на сайт. Это создаст совершенно лишнюю нагрузку. Не используйте сессии по пустякам – к примеру, в счетчиках. То, что спайлог называет сессиями, считается, конечно же, на основе статистики заходов, а не с помощью механизма сессий, аналогичного пхп-шному.
К тому же, возьмем поисковик, который индексирует ваш сайт. Если поисковый робот не поддерживает куки, то пхп по умолчанию будет поставлять к ссылкам PHPSESSID, что — согласистесь — может не сильно понравится поисковику, который, по слухам, и так-то динамические ссылки не жалует, а тут вообще при каждом заходе — новый адрес!
Если сессии используются для ограничения доступа к закрытому разделу сайта, то все просто поисковик и не должен его индексировать.
Если же приходится показывать одну и ту же страницу как авторизованным, так и не авторизованным пользователям, то тут поможет такой трюк – стартовать сессию только тем, кто ввел пароль, или тем, у кого уже стартовала сессия.
Для этого в начало каждой страницы вместо просто session_start() пишем

if (isset($_REQUEST[session_name()])) session_start();

1	if (isset($_REQUEST[session_name()])) session_start();

таким образом, Мы стартуем сессию только тем, кто прислал идентификатор.
Соответственно, надо еще в первый раз отправить его пользователю – в момент авторизации.
Если имя и проль верные – пишем session_start()!

Возможные проблемы и их устранение.

Самыми распространенными ошибками, которые выдает РНР при попытке работать с сессиями, являются такие:
Две из них,
Warning: Cannot send session cookie - headers already sent Warning: Cannot send session cache limiter - headers already sent
вызваны одной и той же причиной, решение описано в этом факе здесь
Третья,
Warning: open(/tmp\sess_SID, O_RDWR) failed: No such file or directory (2) in full_script_path on line number (ранее она выглядела, как Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp)),
если перевести ее с английского, подробно объясняет проблему: недоступен указанный в php.ini путь к каталогу, в который пишутся файлы сессий. Эту ошибку исправить проще всего. Просто прописать каталог, который существует, и доступен на запись, например,
session.save_path = c:\windows\temp
И не забыть перезагрузить апач после этого.

Как выясняется, сообразительность людская не имеет пределов, и поэтому я вынужден пояснить:
сообщение о третьей ошибке (невозможно найти каталог) НЕИЗБЕЖНО приведет к появлению первых двух, поскольку сообщение об ошибке — это вывод в браузер и после него заголовками пользоваться нельзя. Поэтому не спешите искать преждевременный вывод, а сначала пропишите правильный путь!

Следующей по распространенности проблемой при работе с сессиями является тяжелое наследие register_globals. НЕ давайте переменным скрипта имена, совпадающие с индексами массива $_SESSION!
При register_globals=on значения будут перезаписывать друг друга, и вы запутаетесь.
А при register_globals=off появится другая ошибка: «Your script possibly relies on a session side-effect which existed until PHP 4.2.3.», в случае, если в скрипте есть переменная сессии не имеющая значения, и глобальная переменная с тем же именем. Чтобы от неё избавиться, надо всегда инициализировать переменные перед использованием (или хотя бы проверять на существование) и не давать глобальным переменным имена, совпадающие с индексами массива $_SESSION.

Если не работает, но и никаких сообщений не выводится, то добавьте в самое начало скрипта две строчки, отвечающие за вывод ВСЕХ ошибок на экран — вполне возможно, что ошибки есть, но вы их просто не видите.

ini_set('display_errors',1);
error_reporting(E_ALL);

1 2	ini_set('display_errors',1); error_reporting(E_ALL);

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

Если вы уверены, что ошибок нет, но приведенный пример не работает все равно, то, возможно, в PHP не включена передача ид через урл, а куки по каким-то причинам не работают.
Смотрите, что у вас с куками.
Вообще, если у вас «не работают» сессии, то сначала попробуйте передать идентификатор сессии руками, то есть, сделать ссылку и приписать к ней идентификатор:

<? 
session_start(); 
if (!isset($_SESSION['counter'])) $_SESSION['counter']=0;
echo "Вы обновили эту страницу ".$_SESSION['counter']++." раз.<br>
<a href=".$_SERVER['PHP_SELF'].'?'.session_name().'='.session_id().">обновить</a>"; 
?>

session_start();

if (!isset($_SESSION['counter'])) $_SESSION['counter']=0;

echo "Вы обновили эту страницу ".$_SESSION['counter']++." раз.<br>

<a href=".$_SERVER['PHP_SELF'].'?'.session_name().'='.session_id().">обновить</a>";

При этом следует убедиться, что не включена директива session.use_only_cookies, которая запрещает PHP принимать идентификатор сессии, если он был передан через URL

Если этот пример не заработает, то проблема либо в банальных опечатках (половина «проблем» с сессиями происходит от неправильно написанного имени переменной), либо в слишком старой версии PHP: поддержка сессий появилась в версии 4.0, а массив $_SESSION — в 4.1 (До этого использовался $HTTP_SESSION_VARS).
Если же заработает — то проблема в куках. Отслеживайте — что за куку ставит сервер браузеру, возвращает ли браузер ее. Искать очень полезно, просматривая просматривая обмен HTTP-заголовками между браузером и сервером.
Объяснение принципа работы кук выходит за рамки этого и так уж слишком большого текста, но хотя бы убедитесь, что сервер куку с идентификатором посылает, а браузер — возвращает. И при этом идентификаторы совпадают друг с другом =)
Установка куки должна выглядеть, как
Set-Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6;
или как
Set-Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6; path=/
(если вы запрашиваете скрипт не из корневого каталога)
Ответ сервера должен выглядеть, как
Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6
либо
Cookie: PHPSESSID=prlgdfbvlg5fbsbshch6hj0cq6; b=b
если браузер возвращает другие куки, кроме идентификатора сессии.

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

Если пример отсюда работает, а ваш собственный код — нет, то проблема, очевидно, не в сессиях, а в алгоритме. Ищите, где потеряли переменную, по шагам переносите пример отсюда, отлаживайте свой скрипт.

Еще одна проблема может возникнуть, если вы используете перенаправление через header или навигацию с помощью JavaScript.
Дело в том, что РНР автоматически дописывает идентификатор сессии только к ссылкам вида <a href=>, но не делает этого для header-ов, яваскрипта, мета-тегов.
Поэтому надо добавлять идентификатор руками, например, так:

header("Location: /script.php?".session_name().'='.session_id());

1	header("Location: /script.php?".session_name().'='.session_id());

Следует помнить, что пхп лочит файл сессии. То есть, если один ваш скрипт стартует сессию и долго выполняется, а другой пытается в это время стартовать её с тем же идентификатором, то он зависнет. Поэтому в долго выполняющихся скриптах следует стартовать сессию только тогда, когда она нужна, и тут же закрывать её, с помощью session_write_close()

Так же, весьма редкая, и совершенно непонятно, откуда появляющаяся, проблема бывает в том, что настройка session.save_handler имеет значение, отличное от files. Если это не так — исправляйте.

Безопасность
Безопасность сессий — тема обширная. Поэтому остановлюсь на нескольких основных моментах.
Самый хрестоматийный — не передавать идентификатор через адресную строку. Об этом написано даже в php.ini, но это ограничивает функциональность сессий. Если вы решите последовать этому совету, то кроме session.use_trans_sid = 0 не забудьте session.use_only_cookies = 1
Желательно привязывать сессию к IP адресу: таким образом, если идентификатор будет украден, то злодей все равно не сможет им воспользоваться в большинстве случаев.
Рекомендуется пользоваться директивой session.save_path, с помощью которой задать собственный каталог для сохранения файлов сессий. Это более безопасно, чем когда они хранятся в общем временном каталоге сервера по умолчанию.

Дополнительная информация:

Кроме кук, механизм сессий посылает еще и заголовки, запрещающие кэширование страниц (тот самый cache limiter). Для html это правильно и необходимо. Но вот когда вы пытаетесь скриптом, проверяющим авторизацию, отдать файл, то интернет эксплорер отказывается его скачивать. Именно из-за этого заголовка. Вызов

session_cache_limiter("private");

1	session_cache_limiter("private");

перед стартом сессии должен решить проблему.
Как это ни кажется странным, но в массиве $_SESSION нельзя использовать числовые индексы — $_SESSION[1], $_SESSION['10'] — cессии работать не будут.
Где-то между версиями 4.2 и 5.0 невозможно было установить session.use_trans_sid с помощью ini_set(). Начиная с 5.0 уже можно снова.
До версии 4.3.3 куку PHP отправлял куку только если при старте сессии в запросе отсутстввал идентификатор. Теперь же кука посылается при каждом вызове session_start()

Пример авторизации с помощью сессий
Проиллюстрируем все вышенаписанное небольшим примером:
создадим файл auth.php:

<?
if (isset($_POST['auth_name'])) {
  $name=mysql_real_escape_string($_POST['auth_name']);
  $pass=mysql_real_escape_string($_POST['auth_pass']);
  $query = "SELECT * FROM users WHERE name='$name' AND pass='$pass'";
  $res = mysql_query($query) or trigger_error(mysql_error().$query);
  if ($row = mysql_fetch_assoc($res)) {
    session_start();
    $_SESSION['user_id'] = $row['id'];
    $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
  }
  header("Location: http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']);
  exit;
}
if (isset($_GET['action']) AND $_GET['action']=="logout") {
  session_start();
  session_destroy();
  header("Location: http://".$_SERVER['HTTP_HOST']."/");
  exit;
}
if (isset($_REQUEST[session_name()])) session_start();
if (isset($_SESSION['user_id']) AND $_SESSION['ip'] == $_SERVER['REMOTE_ADDR']) return;
else {
?>
<form method="POST">
<input type="text" name="auth_name"><br>
<input type="password" name="auth_pass"><br>
<input type="submit"><br>
</form>
<? 
}
exit;
?>

if (isset($_POST['auth_name'])) {

$name=mysql_real_escape_string($_POST['auth_name']);

$pass=mysql_real_escape_string($_POST['auth_pass']);

$query = "SELECT * FROM users WHERE name='$name' AND pass='$pass'";

$res = mysql_query($query) or trigger_error(mysql_error().$query);

if ($row = mysql_fetch_assoc($res)) {

session_start();

$_SESSION['user_id'] = $row['id'];

$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];

}

header("Location: http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']);

exit;

}

if (isset($_GET['action']) AND $_GET['action']=="logout") {

session_start();

session_destroy();

header("Location: http://".$_SERVER['HTTP_HOST']."/");

exit;

}

if (isset($_REQUEST[session_name()])) session_start();

if (isset($_SESSION['user_id']) AND $_SESSION['ip'] == $_SERVER['REMOTE_ADDR']) return;

else {

</form>

}

exit;

теперь достаточно написать во всех защищаемых скриптах строчку
require «auth.php»;

ОПС! Очень Полезные Ссылки:
http://www.php.net/manual/ru/ref.session.php — самая последняя и свежая информация о поддержке сессий в PHP в официальной документации, плюс многочисленные комментарии пользователей. Настоятельно рекомендуется к прочтению.
http://phpclub.ru/manrus/f/ref.session.html — ВЕСЬМА устаревший перевод этой главы на русский, из документации в переводе Александра Пирамидина.
http://phpclub.ru/detail/article/sessions
Статья с пафосным названием «Правда о сессиях». Двойственное впечатление оставляет. Вначале автор ОЧЕНЬ доступно рассказывает о механизме сессий, но методы, которые он предлагает к концу статьи — совершенно мутные.

Хрестоматийная статья Дмитрия Бородина с сайта
http://php.spb.ru/ настоятельно НЕ рекомендуется.
Ребята, она страшно устарела. Мало того, что в ней есть фактические неточности, так с сессиями в PHP уже давно просто не работают.
Огромное Диме спасибо за нее, это была первая статья по сессиям на русском языке, я сам по ней учился, но сейчас надо ее отправить на заслуженный отдых.
Так же, устарели к сожалению, и многие другие статьи, лежащие в интернете и не обновлявшиеся годами.

Источник: http://phpfaq.ru/sessions

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Ubuntu: установка и настройка связки nginx + apache + php + mysql

Posted on 13.10.2015 by rudjuk 9 комментариев

В это статье я расскажу как быстро развернуть LAMP сервер на Ubuntu с кеширующим nginx

Для всех команд необходим sudo, потому сразу войдем для удобства в этот режим:

sudo su

sudo su

Далее, обновляем данные из репозитариев:

apt-get -y update

1	apt-get -y update

Установка MySQL сервер:

apt-get install mysql-server mysql-client

1	apt-get install mysql-server mysql-client

Во время установки нас попросят ввести пароль root для сервера MySQL, вводим 2 раза. Дожидаемся окончания установки.

Установка Apache, nginx, php:

apt-get install apache2 nginx apache2-mpm-prefork apache2-utils libapache2-mod-php5 php5 php5-dev php5-mysql php5-common php5-curl php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-mhash php5-ming php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl

1	apt-get install apache2 nginx apache2-mpm-prefork apache2-utils libapache2-mod-php5 php5 php5-dev php5-mysql php5-common php5-curl php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-mhash php5-ming php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl

Дожидаемся окончания установки.
Включаем модули rewrite и include в apache2 при помощи утилиты — a2enmod:

a2enmod rewrite
a2enmod include

1 2	a2enmod rewrite a2enmod include

Меняем порт в apache2 со стандартного 80 на 8080 (2 строчки):

nano /etc/apache2/ports.conf
NameVirtualHost *:8080
Listen 8080

nano /etc/apache2/ports.conf

NameVirtualHost *:8080

Listen 8080

Создаем новый веб сервер (VirtualHost), создаем файл конфигурации:

touch /etc/apache2/sites-available/domain.com

1	touch /etc/apache2/sites-available/domain.com

И вставляем в него следующий текст:

<VirtualHost *:8080>
ServerName domain.com
ServerAlias www.domain.com
ServerAdmin admin@domain.com
DocumentRoot /var/www/domain.com
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/domain.com/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
ErrorLog /var/log/domain.com_error.log
LogLevel warn
CustomLog /var/log/domain.com_access.log combined
</VirtualHost>

ServerName domain.com

ServerAlias www.domain.com

ServerAdmin admin@domain.com

DocumentRoot /var/www/domain.com

Options FollowSymLinks

AllowOverride None

</Directory>

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Order allow,deny

allow from all

</Directory>

ErrorLog /var/log/domain.com_error.log

LogLevel warn

CustomLog /var/log/domain.com_access.log combined

</VirtualHost>

Далее, создаем папку сайта и запускаем сайт:

mkdir -p /var/www/domain.com
a2ensite domain.com

1 2	mkdir -p /var/www/domain.com a2ensite domain.com

Проверяем в браузере — http://domain.com:8080

Конфигурируем nginx:

nano /etc/nginx/nginx.conf

1	nano /etc/nginx/nginx.conf

Приводим конфиг к такому виду:

    user www-data;
    worker_processes 4; #По количеству ядер
    pid /var/run/nginx.pid;
    error_log /sites/nginx/error.log;
    events {
    worker_connections 4096;
    multi_accept on;
    }

    http {

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    server_tokens off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log /var/log/nginx-access.log;
    error_log /var/log/nginx-error.log;

    gzip on;
    gzip_disable «msie6″;
    gzip_proxied any;
    gzip_min_length 500;
    gzip_proxied expired no-cache no-store private auth;
    gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
    }

user www-data;

worker_processes 4; #По количеству ядер

pid /var/run/nginx.pid;

error_log /sites/nginx/error.log;

events {

worker_connections 4096;

multi_accept on;

}

http {

sendfile on;

tcp_nopush on;

tcp_nodelay on;

keepalive_timeout 65;

types_hash_max_size 2048;

server_tokens off;

include /etc/nginx/mime.types;

default_type application/octet-stream;

access_log /var/log/nginx-access.log;

error_log /var/log/nginx-error.log;

gzip on;

gzip_disable «msie6″;

gzip_proxied any;

gzip_min_length 500;

gzip_proxied expired no-cache no-store private auth;

gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;

include /etc/nginx/conf.d/*.conf;

include /etc/nginx/sites-enabled/*;

}

Далее создаем и правим конфиг нашего сайта:

nano /etc/nginx/sites-enabled/domain.com

1	nano /etc/nginx/sites-enabled/domain.com

Вносим в него следующие записи:

    upstream backend {
    server 127.0.0.1:8080;
    }
    server {
    listen 80;
    server_name domain.com www.domain.com;

    access_log /var/log/nginx-access.log;
    error_log /var/log/nginx-error.log;

    location / {
    proxy_pass http://backend;
    include /etc/nginx/proxy.conf;
    }
    location ~* .(jpg|jpeg|gif|png|ico|css|bmp|swf|js|mov|avi|mp4|mpeg4) {
    root /var/www/domain.com;
    }

    location ~ /.ht {
    deny all;
    }
    }

upstream backend {

server 127.0.0.1:8080;

}

server {

listen 80;

server_name domain.com www.domain.com;

access_log /var/log/nginx-access.log;

error_log /var/log/nginx-error.log;

location / {

proxy_pass http://backend;

include /etc/nginx/proxy.conf;

}

location ~* .(jpg|jpeg|gif|png|ico|css|bmp|swf|js|mov|avi|mp4|mpeg4) {

root /var/www/domain.com;

}

location ~ /.ht {

deny all;

}

Перезапускаем сервисы и проверяем работу:

service apache2 restart
service nginx restart

1 2	service apache2 restart service nginx restart

Источник: http://evolan.org/linux/ubuntu-ustanovka-i-nastrojka-svyazki-nginx-apache-php-mysql/

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Сброс пароля локального администратора Windows Server 2008R2 / 2008

Posted on 13.10.2015 by rudjuk Leave a comment

Случился такой казус. Как то месяцев восемь назад установил сервер клиенту под управлением Windows Server 2008R2 Foundation. Поставил пароль, записал на всякий случай. И вот недавно потребовалось поднять на этом сервере, сервер терминалов для работы пользователей в «1С:Підприємство». Система все это время отлично шуршала, делался backup баз, ИБП не подводил, и все работало 24\7 как положено. Соответственно сервер залочился и ждал ввода пароля для входа в систему. На ввод моего записанного пароля получил ответ «Неверно указан пользователь или пароль». Соответственно согрешив на раскладку, сменил и ввел пароль на русской раскладке. Эффект такой же. Покопавшись часик, перепробовав все мыслимые и не мыслимые пароли пришел к выводу что пароль и правда, кто то сменил. Войти в систему нужно, а пароля нет. Учетка только «Гость» и из под нее ничего не сделаешь. Попробовал загрузиться со старенького LiveCD который все время с собой таскаю, получил ошибку про не найденный драйвер к RAID контроллеру. Но выход нашелся. Итак, сегодня мы сбросим пароль локального Администратора на Windows Server 2008R2. (Пробовал так же на Windows Server 2008, сбрасывает отлично.) Способ так же подходит для Windows Seven, Vista, и возможно XP. НО! Это не способ сброса пароля Администратора Active Directory. Для тех кто не понял. Пароль администратора домена этим способом не сбросить. Про сброс паролей AD я напишу позднее.

Перед тем как пробовать выполнить рекомендации данной статьи, советую посмотреть другую мою статью про Сброс пароля локального администратора на Windows Server 2008R2, возможно предложенное в ней решение, будет более простым для Вас. Кроме того, описанный на этой странице способ, в некоторых случаях не срабатывает. Причин, к сожалению, я назвать не могу, ибо не знаю.

Для начала нам потребуется небольшой LiveCD который вы можете скачать тут. Размер образа всего 5Мб. Качаем архив, распаковываем и записываем на болванку. И загружаемся с него. И видим следующее:

Просто жмем Enter. В большинстве случаев настроек по умолчанию хватает. Следующий экран предложит найденные партиции жёсткого диска. Снова жмем Enter:

Если работа вашей ОС на которой вы собираетесь сбросить пароль была завершена не корректно то будет предложено сбросить систему. Вводим Y и жмем Enter. Теперь выбор расположения папки конфигурации. Обычно это «Windows/System32/config». Жмем Enter.

Выбор операции которую мы хотим произвести: 1 –Сброс паролей. 2 – Консоль восстановления. q – выход. Вводим 1 и жмем Enter.

Выбираем «1» – Редактирование пользователей и паролей. («9» редактор реестра. Будьте аккуратнее, поддерживается не полностью и есть очень большой шанс грохнуть систему.) Ввeли «1» и нажали enter.

Итак Вы попали в самое «сердце». Пользователи, имеющие привилегии Администратора помечены меткой Admin. Графа «Lock» указывает, стоит ли пароль на учетной записи. Если пароль пустой будет *BLANK*. Что бы отредактировать пользователя нужно ввести либо имя пользователя, либо его RID. Так как имя пользователя у меня на кириллице я ввожу RID в формате 0x. В моем случае RID Администратора будет 01f4, и я вожу 0x01f4. RID для каждого пользователя указаны в колонке с права:

Выбираем действие, которое нужно произвести. «1» – очистка пароля выбранного пользователя. «2» – Редактирование пароля пользователя. «3»– Повысить пользователя до администратора. «4» – Разблокировать заблокированную или отключенную учетную запись. «q» – выход. Жмем 1 и Enter.

И если все прошло удачно получим вот такой экран:

Осталось дело за малым, сохранить сделанные изменения. Вводим «!» и жмем Enter. На следующем экране вводим «q» и снова Enter. Получим запрос на подтверждение сохранения изменений:

Вот и все. Перезагружайте систему удобным для вас способом, например Ctrl + Alt + Delete и входите на свой сервер.

Источник: http://melfis.ru/%D1%81%D0%B1%D1%80%D0%BE%D1%81-%D0%BF%D0%B0%D1%80%D0%BE%D0%BB%D1%8F-%D0%BB%D0%BE%D0%BA%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE-%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82/#comment-5255

Hack

Страница 1 из 212 »