Информационный портал К2® | PHP, Java, Delphi, 3D

Горячик клавиши mc и mcedit

Posted on 14.11.2015 by rudjuk Leave a comment

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

В мануалах и справках клавишу Ctrl обозначают как C, а M — это клавиша Alt.
Если команда пишеться через «-» это означает что они нажимаются совместно.
Если через пробел, то после нажатия первой (отпуская первую) нажимают следующую.

В главном окне mc (midnight commander)

C-O	переключение на subshell и обратно
M-c	сменить текущий каталог (возникает необходимость когда в командной строке уже что-то набрано)

В mcedit:

F3	начать выделение / закончить выделение
F5	скопировать выделенный текст
F6	переместить выделенный текст
F8	удалить выделенный текст
M-L	перейти к строке с номером
M-B	перейти к парной скобке (полезная вещь для программеров, и не только)
С-F	скопировать выделенный блок в файл буфер
C-U	отменить последнее действие
С-K	удалить до конца строки от текущей позиции курсора
С-Y	удалить строку
C-Z	перейти к началу предыдущего слова
C-X	перейти к концу следующего слова

Linux

Резервное копирование баз данных Postgresql в Linux

Posted on 10.11.2015 by rudjuk Leave a comment

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

Вот вариант резервного копирования для 3-х баз данных:

dump_path="/fw/backup/1cbases"

# Устанавливаем разделитель для элементов массива, предварительно резервируя системный:
oldIFS==$IFS
IFS=";"

# Названия баз данных, которые будем сохранять, перечисленные через разделитель, заданный выше
dump_bases="BASE1;BASE2;BASE2"

# Срок хранения резервных копий, дней:
dump_keepdays="7"


PGPASSWORD=ВАШ_ПАРОЛЬ
export PGPASSWORD


for dump_base in $dump_bases; do

# Создаём дамп от имени пользователя postgres, в сжатый файл с именем вида %dbname%-yyyy-mm-dd.sql.gz
pg_dump -h 192.168.77.75 $dump_base --username=postgres | gzip > $dump_path/$dump_base-`date \+\%Y-\%m-\%d`.sql.gz

find $dump_path/$dump_base*.sql.gz -mtime +$dump_keepdays -exec /bin/rm '{}' \;

done

PGPASSWORD=
export PGPASSWORD

# Восстанавливаем стандартный (системный) разделитель списков
IFS=$oldIFS

exit 0

dump_path="/fw/backup/1cbases"

# Устанавливаем разделитель для элементов массива, предварительно резервируя системный:

oldIFS==$IFS

IFS=";"

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

dump_bases="BASE1;BASE2;BASE2"

# Срок хранения резервных копий, дней:

dump_keepdays="7"

PGPASSWORD=ВАШ_ПАРОЛЬ

export PGPASSWORD

for dump_base in $dump_bases; do

# Создаём дамп от имени пользователя postgres, в сжатый файл с именем вида %dbname%-yyyy-mm-dd.sql.gz

pg_dump -h 192.168.77.75 $dump_base --username=postgres | gzip > $dump_path/$dump_base-`date \+\%Y-\%m-\%d`.sql.gz

find $dump_path/$dump_base*.sql.gz -mtime +$dump_keepdays -exec /bin/rm '{}' \;

done

PGPASSWORD=

export PGPASSWORD

# Восстанавливаем стандартный (системный) разделитель списков

IFS=$oldIFS

exit 0

Сохранение бекапа на удаленном сервере по ssh

В условиях отсутствия локального или сетевого тома для хранения резервных копий (несколько натянутое условие, но мне пришлось столкнуться), пришлось доработать скрипт; отличие от изначального скрипта — результат дампа не сохраняется локально, а передаётся на удалённый сервер по ssh и там же производится удаление устаревших файлов:

#!/bin/sh
# Для инструкций по восстановлению см. postgresql.org/docs/8.1/static/backup.html
# Путь на сервере резервирования, куда будем складывать резервные копии
dump_path="/mnt/backup/pgsql"
# Устанавливаем разделитель для элементов массива, предварительно резервируя системный:
oldIFS==$IFS
IFS=";"
# Названия баз данных, которые будем сохранять, перечисленные через разделитель, заданный выше
dump_bases="office_upp;buh_retail;zup"
# Срок хранения резервных копий, дней:
dump_keepdays="7"
# Создаём информационный файл в каталоге назначения ("для будущих поколений")
ssh -i /root/nbs01/backup backup@192.168.122.1 \
 "echo `date \+\%F\ \%T` Dumps of databases. For restoring see postgresql.org/docs/9.3/static/backup.html > $dump_path/readme.txt"
for dump_base in $dump_bases; do
# Создаём дамп от имени пользователя postgres, передавая текстовый дамп по ssh на удалённый сервер,
# сжимая там результат gzip'ом и сохраняя в файл с именем вида %dbname%-yyyy-mm-dd-hh-mm-ss.pgdump.gz
  sudo -u postgres pg_dump -Fc $dump_base | ssh -i /root/nbs01/backup backup@192.168.122.1 \
                                        "gzip > $dump_path/$dump_base-`date \+\%Y-\%m-\%d-\%H-\%M-\%S`.pgdump.gz"
  # Ищем в каталоге резервных копий все файлы с именами похожими на бэкап текущей БД и старше срока хранения и удаляем
  ssh -i /root/nbs01/backup backup@192.168.122.1 \
      "find $dump_path/$dump_base* -mtime +$dump_keepdays -exec /bin/rm '{}' \;"
done
ssh -i /root/nbs01/backup backup@192.168.122.1 \
 "echo `date \+\%F\ \%T` All data keeps $dump_keepdays days, older files will be removed automatically. >> $dump_path/readme.txt"
# Восстанавливаем стандартный (системный) разделитель списков
IFS=$oldIFS

#!/bin/sh

# Для инструкций по восстановлению см. postgresql.org/docs/8.1/static/backup.html

# Путь на сервере резервирования, куда будем складывать резервные копии

dump_path="/mnt/backup/pgsql"

# Устанавливаем разделитель для элементов массива, предварительно резервируя системный:

oldIFS==$IFS

IFS=";"

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

dump_bases="office_upp;buh_retail;zup"

# Срок хранения резервных копий, дней:

dump_keepdays="7"

# Создаём информационный файл в каталоге назначения ("для будущих поколений")

ssh -i /root/nbs01/backup backup@192.168.122.1 \

"echo `date \+\%F\ \%T` Dumps of databases. For restoring see postgresql.org/docs/9.3/static/backup.html > $dump_path/readme.txt"

for dump_base in $dump_bases; do

# Создаём дамп от имени пользователя postgres, передавая текстовый дамп по ssh на удалённый сервер,

# сжимая там результат gzip'ом и сохраняя в файл с именем вида %dbname%-yyyy-mm-dd-hh-mm-ss.pgdump.gz

sudo -u postgres pg_dump -Fc $dump_base | ssh -i /root/nbs01/backup backup@192.168.122.1 \

"gzip > $dump_path/$dump_base-`date \+\%Y-\%m-\%d-\%H-\%M-\%S`.pgdump.gz"

# Ищем в каталоге резервных копий все файлы с именами похожими на бэкап текущей БД и старше срока хранения и удаляем

ssh -i /root/nbs01/backup backup@192.168.122.1 \

"find $dump_path/$dump_base* -mtime +$dump_keepdays -exec /bin/rm '{}' \;"

done

ssh -i /root/nbs01/backup backup@192.168.122.1 \

"echo `date \+\%F\ \%T` All data keeps $dump_keepdays days, older files will be removed automatically. >> $dump_path/readme.txt"

# Восстанавливаем стандартный (системный) разделитель списков

IFS=$oldIFS

Предварительно надо создать авторизационный ключ для пользователя (в приведённом скрипте пользователь — backup) на сервере резервного хранения и разместить приватный ключ в каталоге, доступном на чтение только пользователю root (в приведённом скрипте ключ лежит в файле /root/nbs01/backup) и настроить sshd удалённого сервера на авторизацию по ключам — об этом весьма подробно написано, например, в этой статье.
Да, трафик будет весьма серьёзным, несмотря на возможность сжатия ssh, но конкретно данное решение работает в виртуальной среде, где 3 гигабайта дампа передаются примерно за полторы минуты, что вполне приемлемо.

Восстановление базы данных из дампа

Тут всё просто — если владелец (имя «роли входа» или пользователь postgresql, указанный владельцем изначальной БД) уже существует, но нет самой базы данных, команда восстановления будет выглядеть примерно так:

/usr/pgsql-9.2/bin/pg_restore -e -j 8 -U root -W -d upp /root/files/upp-2013-11-20.pgdump

Восстановление будет выполнено в 8 потоков (для ускорения процедуры, в документации pgsql рекомендуется использовать потоков не меньше, чем доступно ядер CPU) от имени пользователя root с интерактивным вводом пароля. Файл /mnt/arc/1C8/upp-2013-11-20-09-45-51.pgdump — распакованный .gz из второго примера или изначальный дамп из первого. Целевая база (в данном примере — upp) должна уже существовать, и быть созданной из template0.

Если пользователя-владельца создать нет возможности/желания, можно добавить ключ --no-owner да и вообще, почитать что пишут на http://www.postgresql.org/docs/9.3/static/backup.html

И ещё, если на создание дампа в пару гигабайт (несжатых) уходит пара минут, то на восстановление данного дампа в один поток (если не указать ключ распараллеливания — «-j 8» в примере выше) потребуется уже полчасика, на том же железе. А если использовать текстовые дампы (не указать «-F c» при создании дампа, и для восстановления использовать стандартную команду psql dbname < infile или использовать конвейер типа pg_restore infile.pgdump | psql), времени потребуется ещё больше — данные методы целесообразно использовать не для полного восстановления, а когда требуется восстановить только определённую часть базы данных.

Для восстановления БД с удалённой машины (сервера хранилища) можно использовать конструкцию вида:

zcat upp-2014-10-22-07-30-03.pgdump.gz | ssh 192.168.1.2 «psql upp-copy > /root/files/log-create»

Здесь zcat — команда вывода содержимого архива на stdout, upp-2013-10-22-07-30-03.pgdump.gz — имя восстанавливаемого архива, 192.168.1.2 — сервер postgresql, на который восстанавливаем дамп, upp-copy — имя базы данных, в которую разворачиваем дамп (на момент восстановления должна существовать, быть пустой, и иметь необходимые права для «роли входа», использованной в изначальной БД); чтобы не засорять экран выводом psql о процессе создания объектов, перенаправим вывод в файл (сообщения об ошибках, в случае их наличия, будут выводиться в терминал). В данном примере предполагается, что у пользователя, от имени которого мы подключаемся по ssh к серверу postgres есть право работать с базами данных, поэтому авторизация в БД не описана.

Резервное копирование MySQL

Вариант для реализации резервного копирования MySQL:

#!/bin/bash

# user & password
USER=root
PASS=pass

# number of backups to be saved
KEEP=14

# dir to backup
DIR=/var/backups/mysql

NOW=$(date +"%Y-%m-%d")
DBS="$(mysql -u $USER -p$PASS -Bse 'show databases')"

for db in $DBS
do

  BACKUPS=`find $DIR -name "$db.*.gz" | wc -l | sed 's/\ //g'`
  while [ $BACKUPS -ge $KEEP ]
  do
    ls -tr1 $DIR/$db.*.gz | head -n 1 | xargs rm -f
    BACKUPS=`expr $BACKUPS - 1`
  done
  
  FILE=$DIR/$db.$NOW-$(date +"%T").sql.gz
  mysqldump -u $USER -p$PASS $db | gzip -9 > $FILE

done

exit 0

#!/bin/bash

# user & password

USER=root

PASS=pass

# number of backups to be saved

KEEP=14

# dir to backup

DIR=/var/backups/mysql

NOW=$(date +"%Y-%m-%d")

DBS="$(mysql -u $USER -p$PASS -Bse 'show databases')"

for db in $DBS

BACKUPS=`find $DIR -name "$db.*.gz" | wc -l | sed 's/\ //g'`

while [ $BACKUPS -ge $KEEP ]

ls -tr1 $DIR/$db.*.gz | head -n 1 | xargs rm -f

BACKUPS=`expr $BACKUPS - 1`

done

FILE=$DIR/$db.$NOW-$(date +"%T").sql.gz

mysqldump -u $USER -p$PASS $db | gzip -9 > $FILE

done

exit 0

Еще один способ резервного копирования Postgresql

#!/bin/bash

# user & password
USER=postgres
PASS=pass

# number of backups to be saved
KEEP=14

# dir to backup
DIR=/var/backups/pgsql

PGPASSWORD=$PASS
export PGPASSWORD

NOW=$(date +"%Y-%m-%d")
DBS="$(psql -U $USER -lt |awk '{ print $1}' |grep -vE '^-|^List|^Name|template[0|1]')"

for db in $DBS
do

  BACKUPS=`find $DIR -name "$db.*.gz" | wc -l | sed 's/\ //g'`
  while [ $BACKUPS -ge $KEEP ]
  do
    ls -tr1 $DIR/$db.*.gz | head -n 1 | xargs rm -f
    BACKUPS=`expr $BACKUPS - 1`
  done
  
  FILE=$DIR/$db.$NOW-$(date +"%T").sql.gz

  pg_dump -U $USER $db | gzip -c > $FILE

done

PGPASSWORD=
export PGPASSWORD

exit 0

#!/bin/bash

# user & password

USER=postgres

PASS=pass

# number of backups to be saved

KEEP=14

# dir to backup

DIR=/var/backups/pgsql

PGPASSWORD=$PASS

export PGPASSWORD

NOW=$(date +"%Y-%m-%d")

DBS="$(psql -U $USER -lt |awk '{ print $1}' |grep -vE '^-|^List|^Name|template[0|1]')"

for db in $DBS

BACKUPS=`find $DIR -name "$db.*.gz" | wc -l | sed 's/\ //g'`

while [ $BACKUPS -ge $KEEP ]

ls -tr1 $DIR/$db.*.gz | head -n 1 | xargs rm -f

BACKUPS=`expr $BACKUPS - 1`

done

FILE=$DIR/$db.$NOW-$(date +"%T").sql.gz

pg_dump -U $USER $db | gzip -c > $FILE

done

PGPASSWORD=

export PGPASSWORD

exit 0

Источники: http://www.bubnov.su/stati/rezervnoe-kopirovanie-baz-dannyh-postgresql

http://habrahabr.ru/post/82278/

Перегенерация значений полей left_key и right_key в Shop-Script

Posted on 05.11.2015 by rudjuk Leave a comment

В Shop-Scropt ведутся промежуточные поля left_key, right_key. Они влияют на отображение дерева. Если данные поля заполнены не корректно, то ваше дерево может «развалиться» и вести не адекватно.

Починить данную ситуцию Вы можете с помощью команд:

$model = new shopCategoryModel();
$model->repair();

1 2	$model = new shopCategoryModel(); $model->repair();

Или выполнив из URL:

/webasyst/shop/?module=repair&action=categories

1	/webasyst/shop/?module=repair&action=categories

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

Интернет-магазины

Настройка SSH в GitLib

Posted on 03.11.2015 by rudjuk Leave a comment

При вставке больших файлов в GitLib, используя http-доступ возникает ошибка 413 и как результат — файлы не передаются. В таком случае, лучше передавать информацию через ssh. Но, для этого, нужно несколько повозиться и настроить ssh-ключи. В данной статье описывается, как настроить ssh-доступ для GitLib.

После создания нового проекта стоит обратить внимание на 2 вещи:

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

gitlib ssh

Начнем с SSH ключей. Стоит различать 2 разновидности SSH пар ключей — которые использует Git и которые используют клиенты типа Source Tree, Tortoise Git. Проблема первой разновидности в том, что без лишних телодвижений допускается использование только одной пары ключей, в то время как каждый репозиторий требует уникальный ключ, вторых же можно наплодить неограниченное количество (на самом деле можно использовать более 1 пары ключей первого типа, но предлагаемые решения работают либо частично, либо не работают вообще).

Для начала, сделаем ключи для Git, для этого запустим Git Bash. Git подразумевает что в Windows среде ключи лежат по адресу ~ / .ssh / id_rsa, где ~ — путь к домашней директории пользователя (например c: \ Users \ USERNAME), в папке которого есть каталог .ssh, в котором лежит пара ключей — id_rsa.pub и id_rsa (соответственно публичная часть и приватная).

Пришло время для генерирования ключей, возвращаемся к Git Bash и в консоль вводим следующее:

ssh-keygen -t rsa -C «your_email@example.com»»

Данная команда указывает Git Bash создать ключ с коментарием your_email@example.com (зачем он нужен, поймете чуть позже) в формате RSA. Внимательно вводим место сохранения ключа, в nix-like стиле с прямыми (а не обратными!!!) слешами:

c: / Users / USERNAME / .ssh / id_rsa

и дважды вводим пароль для дополнительной защиты ключа (passphrase):

ssh key git

Переходим в личном кабинете в профиль, на вкладку с SSH ключами:

Профиль ssh gitlab

и добавляем содержимое посредством Copy/Paste файла id_rsa.pub (title заполнять не нужно — подставляется автоматически из коментария к ключу, таким образом ключи удобно отличать визуально, не сравнивая fingerprints.)

GitLab Профиль ssh

Убеждаемся что файл принят системой:

Gitlab ssh key profile

HTTP доступ к репозиторию

Настала очередь собственно локального репозитория. Возвращаемся в Git Bash и поочередно вводим команды, которые услужливо подсказывает стартовая страница вашего проекта:

cd d: / projects / test — переходим в папку где будет лежать будущий проект

mkdir test-project — создаем новую папку для проекта

cd test-project — переходим в папку проекта

git init — инициализируем локальный репозиторий

touch README — создаем новый файл README

git add README — добавляем его к версионированию

git commit -m ‘first commit’ — делаем commit с коментарием о первом комите

git remote add origin http://gitlab.golovachcourses.com/Student/test-project.git — добавляем адрес удаленного репозитория в HTTP формате

git push -u origin master — отправляем изменения на сервер

Теперь если зайти в свой личный кабинет, то сначала увидим сообщение про создание новой ветки master в нашем тестовом проекте:

В файлах появился новый файл README:

но он пока пустой.

Галочка в зеленом кружочке сообщает что данная папка успешно подключена к VCS:

Итак, мы создали первый тестовый проект, подключили его к удаленному репозиторию по HTTP протоколу и сделали первый commit первого файла — README.

SSH доступ к репозиторию

Попробуем теперь изменить файл README и отправить изменения на сервер посредством SSH протокола через Tortoise Git. Для удаленного обновления вашего кода через Tortoise Git необходимо настроить и добавить к аккануте новыю пару SSH ключей, используя PuTTY Key Generator:

Полученную пару ключей необходимо сохранить (Save public key && Save private key) в том же месте где и предыдущие для дальнейшей настройки Git (пусть это будут соответственно test@gitlab.golovachcourses.com.pub и test@gitlab.golovachcourses.com.ppk).

Теперь добавим к первому сгенерированный ключ в вашем профиле:

В параметре Git -> Remote -> origin меняем ссылку на SSH вариант:

git@gitlab.golovachcourses.com:Student/test-project.git

и указываем новый PuTTY ключ.

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

Обратите внимание на то, что VCS реагирует на изменение локальной копии, которое не синхронизировано с удаленным:

Есть две возможности провести синхронизацию:

отдельно по файлу (так как он у нас один, больше ничего в проекте нет)
либо по всей папке (что делают чаще всего)

В первом случае ПКМ на файле -> Git commit -> «master»…

Во втором случае ПКМ на папке -> Git Sync (этот вариант и рассмотрим как более общий):

делаем commit

вводим описание commit-а

локальный commit прошел успешно, делаем push

вводим пароль для ключа (passphrase, что вводили при создании, понадобится только в первый раз)

git_sync_push_passphrase вводим наш логин

git_sync_push_login пароль

git_sync_push_pass и наслаждаемся сообщением о том что произведен новый commit в основную ветку

и видим что в нашем удаленном файле, доступном в репозитории на сервере уже есть внесенные нами изменения

И теперь папка с «проектом» имеет одинаковую ревизию что локально что удаленно:

Git GUI клиенты

Помимо рассмотренного простейшего Tortoise Git (который на самом деле является не совсем GUI клиентом а скорее расширением оболочки), существует несколько других, для различных платформ: Git GUI. Из представленных заслуженное внимание привлекает Source Tree — добротный free инструмент от компании Atlassian.

Источник: http://gitlab.golovachcourses.com/root/manual/wikis/new_local_repository

git и т.п.)

Git коротко

Posted on 01.11.2015 by rudjuk Leave a comment

Создаем копию проекта:

git clone http://git.corp2.net.net/web/k2shop.git

1	git clone http://git.corp2.net.net/web/k2shop.git

Конфигурирование репозитария:

git config --global user.email "ВАШ@Email"

1	git config --global user.email "ВАШ@Email"

Добавление новых файлов в репозитарий:

git add .

git add .

Сохранение изменений в репозитарий:

git commit -m "ВашКомментарий"

1	git commit -m "ВашКомментарий"

Подключение к удаленному репозитарию:

git remote add origin http://git.corp2.net/ВашРепозитарий/Репозитарий.git

1	git remote add origin http://git.corp2.net/ВашРепозитарий/Репозитарий.git

Добавление изменений в master:

git pull -u origin master

1	git pull -u origin master

Закачка на сервер:

git push

git push

Статус локального репозитатора:

git status

1	git status

git и т.п.)

Git для чайника. Команды которые помогут начать работу

Posted on 01.11.2015 by rudjuk Leave a comment

Многим трудно начать работать с Git, ведь не все привыкли работать с командной строкой, но именно ее лучше всего использовать при работе с репозиторием Git. И сегодня я расскажу о самом простом, так сказать Git для чайника, чтобы помочь освоиться Вам с этой системой. Git представляет собой систему контроля версий, которая позволяет в нужный момент откатиться на старую версию, если вы «наломали дров«.

С помощью Git Вы сможете размещать свой код на GitHub, BitBucket и Google Code.

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

С чего начать?

Нам понадобиться программа Git Bash, это шелл сделанный на основе Cygwin, поэтому возможно использование Unix-команд, вроде ls, cd, mkdir. Скачать его можно по следующей ссылке http://git-scm.com/.

Настройка Git

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

git config --global user.name "Ваше имя"
git config --global user.email "Ваш Email"

1 2	git config --global user.name "Ваше имя" git config --global user.email "Ваш Email"

Также нам нужно настроить параметры установок окончания строк, для Windows мы вводим две команды

git config --global core.autocrlf true
git config --global core.safecrlf false
git config --global core.eol native

git config --global core.autocrlf true

git config --global core.safecrlf false

git config --global core.eol native

На этом настройка заканчивается, можем начинать работу с проектом.

Создание проекта

Допустим у нас есть папка с проектом, которую мы хотим разместить на GitHub.

1. Создаем репозиторий на сайте.

Git

2. Инициализируем папку для Git репозитория. Это нужно сделать только один раз для каждого проекта.

git init

git init

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

git remote add origin https://github.com/LeoXCoder/test_project.git

1	git remote add origin https://github.com/LeoXCoder/test_project.git

4. Добавляем все новые и измененные файлы

git add .

git add .

5. Помечаем все новые и измененные файлы сообщением (commit)

git commit -m "message"

1	git commit -m "message"

— вместо message вписываем сообщение, например Initial Commit. или Bugfix.

6. Закачиваем код на удаленный репозиторий

git push -u origin master

1	git push -u origin master

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

git push

git push

git

git

7. Можно посмотреть статус изменений, которые были сделаны.

git status

1	git status

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

git pull

git pull

Второй компьютер

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

1. Клонирование репозитория

git clone https://github.com/LeoXCoder/test_project.git

1	git clone https://github.com/LeoXCoder/test_project.git

В результате git скачает удаленный репозиторий в новую папку test-project

2. После каких-то изменений в коде, выполняем все те же команды

git add .
git commit -m "I changed the user module."
git push

git add .

git commit -m "I changed the user module."

git push

Откат изменений

1. Полный откат до предыдущего коммита

git reset HEAD --hard

1	git reset HEAD --hard

2. Сброс изменений в файле на версию коммита

git checkout <filename>

1	git checkout <filename>

3. Откат до установленного тега, например v1

git checkout v1

1	git checkout v1

Для более лучшего пониманию лучше ознакомиться с интерактивным туром по Git

git и т.п.)

Собственный хостинг репозиториев с помощью 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

Страница 10 из 31« Первая «...8 91011 12...20 30...»Последняя »