понедельник, 14 октября 2019 г.

установка OnlyOffice

OnlyOffice

Онлайн-редактор документов. Ставится для использования с Nextcloud на отдельный сервер в Docker.
Для работы с внешними пользователями документ-сервер должен быть опубликован в интернете и иметь действительный сертификат SSL, иначе при обращении к документ-серверу через интерфейс Nextcloud будет ошибка «OnlyOffice cannot be reached, please contact admin» из-за того, что браузер не доверяет самоподписанному сертификату и не откроет фрейм документа.
Хост-сервер, где крутится OnlyOffice, должен иметь открытые порты 80 и 443 в интернет.

Установка

Подготовительные действия:
# создать папки
mkdir onlyoffice
cd onlyoffice
mkdir logs data lib db data/certs
# файл с переменными
echo "JWT_ENABLED=true" >> env.list
# secretword - это пароль доступа к документ-серверу
echo "JWT_SECRET=secretword" >> env.list
Установка Docker (для Debian):
sudo apt-get install apt-transport-https ca-certificates curl gnupg2 software-properties-common
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/debian \
   $(lsb_release -cs) \
   stable"
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io
Выпуск сертификата:
certbot certonly -d oo.domain.com
 
Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/oo.domain.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/oo.domain.com/privkey.pem
 
# Копировать сертификаты в каталог их забора при запуске контейнера
cp /etc/letsencrypt/live/oo.domain.com/fullchain.pem ~/onlyoffice/data/certs/onlyoffice.crt
cp /etc/letsencrypt/live/oo.domain.com/privkey.pem ~/onlyoffice/data/certs/onlyoffice.key
chmod 400 ~/onlyoffice/data/certs/onlyoffice.key
 
# Сгенерировать параметры Диффи-Хеллмана (DHE), обеспечивающие более высокую стойкость
openssl dhparam -out ~/onlyoffice/data/certs/dhparam.pem 2048
Запуск:
sudo docker run -i -t -d -p 443:443 --restart=always \
-v ~/onlyoffice/logs:/var/log/onlyoffice  \
-v ~/onlyoffice/data:/var/www/onlyoffice/Data  \
-v ~/onlyoffice/lib:/var/lib/onlyoffice \
-v ~/onlyoffice/db:/var/lib/postgresql \
--env-file ~/onlyoffice/env.list onlyoffice/documentserver
Далее ставится плагин OnlyOffice в Nextcloud и настраивается через веб-интерфейс. Ключ доступа, прописанный ранее в переменной JWT_SECRET, прописывается в доп. настройках.

Дополнительно

# Список контейнеров
sudo docker ps
# Запустить консоль внутри контейнера:
sudo docker exec -it CONTAINER_ID bash
# Перезапуск всех служб OnlyOffice (внутри контейнера)
supervisorctl restart all
Костыль, чтобы заставить Nextcloud не проверять подлинность сертификата для взаимодействия с OnlyOffice. Прописывается в config.php Nextcloud. В нормальной ситуации не нужен.
'onlyoffice' =>
array (
'verify_peer_off' => TRUE,
),

Отключить проверку сертификата в OnlyOffice

Нужно в случае, когда Nextcloud и OnlyOffice стоят в одной подсети и внутренние запросы (в настройках плагина Онлиофиса в Некстклауде) идут через внутренние имена или IP-адреса, отсутствующие в SSL-сертификате. Если не отключить проверку, то при настройке плагина будет выдаваться ошибка: Error while downloading the document file to be converted
Решение:
When you use self-signed certificates they should be added to ca-certificate bundle of the OS of both servers (the one you use on Nextcloud should be added to the server with ONLYOFFICE Document Server and vice versa). The problem is that the certificate of Nextcloud should be also added to nodejs ca-certificate bundle, so the Document Server can verify it. But it is impossible for nodejs version 6, which is required for the Document Server at the moment.
We are working on the possibility to install Document Server with the later versions of nodejs, where it is possible to add self-signed certificates.
As a temporary solution you can disable verification of the certs by the Document Server. It should help. Please change the value of the parameter `"rejectUnauthorized":` from `true` to `false` in /etc/onlyoffice/documentserver/default.json. After that restart all the services of the Document Server:
supervisorctl restart all
sed -ie 's/"rejectUnauthorized": true/"rejectUnauthorized": false/g' /etc/onlyoffice/documentserver/default.json
supervisorctl restart all
Источник:
https://bva.dyndns.info/wiki/service/onlyoffice

Как редактировать файлы контейнера Docker с хоста


Если действительно нужно просто быстро отредактировать файл для проверки чего-либо, либо используйте docker exec, чтобы получить оболочку в контейнере и отредактировать напрямую, либо используйте docker cp, чтобы скопировать файл, отредактировать на хост и копировать обратно.

$ docker cp CONTAINER:FILEPATH LOCALFILEPATH $ vi LOCALFILEPATH $ docker cp LOCALFILEPATH CONTAINER:FILEPATH

Источник:
http://qaru.site/questions/188483/how-to-edit-docker-container-files-from-the-host

сертификаты Let's Encrypt при помощи Certbot

ubuntu
установим необходимое для работы с PPA программное обеспечение:

apt-get install software-properties-common
Затем добавим нужный PPA:

add-apt-repository ppa:certbot/certbot
Обновим список пакетов:

apt-get update
и установим Certbot:

apt-get install certbot

В доступной для веб-сервера директории создадим отдельную папку, скажем, letsencrypt, которую затем мы будем использовать для всех обслуживаемых доменов и установим ее владельцем веб-сервер:
 mkdir /var/www/letsencrypt
chown www-data:www-data /var/www/letsencrypt
Теперь нам нужно сделать так, чтобы любой запрос вида:
http://example.com/.well-known/acme-challenge
приводил к физическому размещению:
/var/www/letsencrypt/.well-known/acme-challenge
Это несложно, но для каждого из веб-серверов делается по-разному, ниже мы рассмотрим самые популярные из них.

Apache 2.x

Apache является самым распространенным и популярным веб-сервером, актуальной версией является 2.4.x, для его подготовки к работе с Certbot добавьте в основной конфигурационный файл /etc/apache2/apache2.conf следующую секцию:
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/


    Options None
    AllowOverride None
    ForceType text/plain
    Require all granted
    RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
Для устаревшей версии Apache 2.2 данный блок должен выглядеть следующим образом:
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/


    Options None
    AllowOverride None
    ForceType text/plain
    Order allow,deny
    Allow from all
    RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
Данная секция создает для любого запроса к /.well-known/acme-challenge алиас (псевдоним), указывающий на физическую директорию /var/www/letsencrypt/.well-known/acme-challenge, а ее расположение в основном конфигурационном файле позволит распространить действие директив для любого обслуживаемого домена. Остальные параметры задают необходимые параметры безопасности.

Nginx

Nginx - второй по популярности веб-сервер (и первый среди продвинутых пользователей) предполагает несколько иной подход к настройке. Для каждого виртуального хоста в секцию server следует добавить блок:
location ^~ /.well-known/acme-challenge/ {
   default_type "text/plain";
   root /var/www/letsencrypt;
}
location = /.well-known/acme-challenge/ {
   return 404;
}
Если вы настраивали сервер по нашей инструкции, то мы рекомендуем вынести указанный блок в отдельный шаблон, например, /etc/nginx/templates/letsencrypt.conf и впоследствии подключать в конфигурацию виртуального хоста именно его и в общих чертах это должно выглядеть так:
server {
   server_name example.com
   ..
   include /etc/nginx/templates/letsencrypt.conf;
}
Данный подход является хорошей практикой, так как в случае внесения каких-либо изменений их придется делать только в одном месте, вне зависимости от числа обслуживаемых виртуальных хостов.

Получение сертификата

Наконец-то мы подошли к самому главному - получению сертификата, но не стоит спешить, количество запросов на сертификат в единицу времени ограничено (20 запросов на регистрацию в неделю и 5 неудачных запросов в час), поэтому следует убедиться, что все сделано правильно. Для этого следует использовать возможность тестового запуска Certbot, наберем в консоли:
certbot certonly --dry-run --webroot -w /var/www/letsencrypt -d example.com -d www.example.com
Ключ --dry-run включает тестовый режим, при котором производится симуляция получения сертификата, --webroot - указывает используемый плагин, после ключа -w указываем путь к директории для letsencrypt, а затем через ключ -d указываем домены для которых мы получаем сертификат. Как минимум это должно быть основное имя сайта и имя c www, хотя никто не мешает включить вам в сертификат все нужные поддомены или вообще разные домены. Лимит на количество доменов в сертификате равен 100.
После того как тестовый запуск увенчался успехом можно переходить к получению сертификата:
certbot certonly --webroot -w /var/www/letsencrypt -d example.com -d www.example.com
Сертификат получен, отлично! Но где нам его искать? Перейдем в /etc/letsencrypt/live где для каждого полученного сертификата будет создана папка с именем первого указанного в запросе домена, т.е. для нашего примера - example.com. Внутри будут находиться четыре файла:
  • cert.pem - собственно сертификат
  • chain.pem - цепочка доверия, включает корневой и промежуточный сертификаты Let's Encrypt
  • fullchain.pem - полная цепочка, включающая кроме содержимого chain.pem сам сертификат
  • privkey.pem - закрытый ключ сертификата, данный файл является секретным.
Именно эти файлы следует использовать в конфигурационных файлах служб при настройке SSL, конкретные реализации выходят за рамки данной статьи и это будет сделано в отдельных материалах, мы же заглянем еще глубже под капот.
При внимательном рассмотрении выяснится, что файлы в директории live являются символьными ссылками на аналогичные файлы в /etc/letsencrypt/archive:

Источник:

напоминалка по netstat

sudo netstat -ltup

Флаг -l указывает netstat вывести все прослушивающие сокеты (сокет это ip + порт), -t показывает все TCP-соединения, -u отображает все соединения UDP, а -p позволяет выводить имя приложения/программы, прослушивающее порт.

Чтобы выводить числовые значения (номер порта), а не имена служб, добавьте флаг -n.

$ sudo netstat -lntup
-------------------------------------------------------------------
s — еще один полезный инструмент для отображения информации о сокетах. Он в своём использовании похож на netstat. Следующая команда выведет все порты прослушивающие соединения TCP и UDP в числовом формате.

$ sudo ss -lntu

Оригинал:
http://blog.sedicomm.com/2019/02/27/4-sposoba-uznat-kakie-porty-proslushivayutsya-v-linux/


1С-Битрикс: Низкие показатели MySQL в мониторе производительности (Решение)


Хочу поделится радостью: удалось оптимизировать работу MySQL.
В БУС монитор производительности на мощном сервере показывал следуюшее:
База данных MySQL (запись)      72      5 600      количество запросов на запись в секунду
База данных MySQL (чтение)      5 869   7 800      количество запросов на чтение в секунду
База данных MySQL (изменение)   4 251   5 800      количество запросов на изменение в секунду
Но нашлась все-таки одна настроечка, которая ну очень сильно меня обрадовала: innodb_flush_log_at_trx_commit=2
После того как я ее прописал, получил следующие циферки:
База данных MySQL (запись)     4 395     5 600     количество запросов на запись в секунду
База данных MySQL (чтение)    6 220    7 800    количество запросов на чтение в секунду
База данных MySQL (изменение)    4 643    5 800    количество запросов на изменение в секунду
Увелечение скорости записи в 60 раз меня ну очень обрадовало.
innodb_flush_log_at_trx_commit — Вам кажется, что InnoDB в сто раз медленнее MyISAM? Вероятно, вы забыли изменить значение этого параметра. Значение по умолчанию 1 означает, что после каждой завершенной транзакции (или после изменения состояния транзакции) лог должен быть сброшен на диск. Это достаточно дорогая операция, особенно если у вас нет Battery backed up cache. Многие приложения, особенно те, в которых раньше использовался MyISAM будут хорошо работать при значении 2, который означает, что не надо сбрасывать буфер на диск, а следует отправить его в кэш операционной системы. Лог по-прежнему будет сбрасываться на диск каждую секунду и максимум, что вы можете потерять — это 1-2 секунды записей. Значение 0 обеспечивает более высокую скорость, но и более низкую надежность. Есть вероятность потерять транзакции даже при падении mysql-сервера. При значении равном 2 единственная возможность потерять данные — это фатальный сбой операционной системы.

Оригинал статьи - в интернете

подсказки по работе с docker

Docker: Удалить Контейнер — Удалить Все Контейнеры

Список Docker-контейнеров
Список запущенных Docker-контейнеров:

$ docker ps
Список всех Docker-контейнеров:

$ docker ps -a
Удалить Docker-контейнер
Удалить Docker-контейнер по CONTAINER ID или NAME:

$ docker rm
Принудительно удалить запущенный Docker-контейнер:

$ docker rm -f
Удалить Все Docker-контейнеры
Удалить все остановленные (неиспользуемые) Docker-контейнеры:

$ docker container prune -f
Принудительно удалить все Docker-контейнеры, включая запущенные контейнеры:

$ docker rm -f $(docker ps -a -q)

Docker: Удалить Образ — Удалить Все Образы — Удалить Неиспользуемые

Список Docker-образов
Список всех локальных Docker-образов:

$ docker images
Удалить Docker-образ
Удалить Docker-образ по IMAGE ID:

$ docker rmi
Принудительно удалить Docker-образ:

$ docker rmi -f
Удалить Неиспользуемые Docker-образы
Удалить все неиспользуемые Docker-образы:

$ docker image prune -a -f
Удалить Все Docker-образы
Принудительно удалить все Docker-образы:

$ docker rmi -f $(docker images -q)

оригинал:

четверг, 13 сентября 2018 г.

Прерывание проверки дискового массива в mdadm

MDADM, поставляемый вместе с дистрибутивом Debian, содержит задание CRON, которое раз в месяц запускает проверку целостности массива. На больших массивах, размер которых превышает несколько терабайт, такая проверка может занять слишком много времени. Прогресс выполнения проверки можно узнать в /proc/mdstat

# cat /proc/mdstat
Personalities : [raid1] 
md1 : active raid1 sdb2[0] sda2[1]
      1911569360 blocks super 1.2 [2/2] [UU]
      [>....................]  check =  0.0% (8832/1911569360) finish=7201.4min speed=4416K/sec
      
md0 : active raid1 sdb1[0] sda1[1]
      41941944 blocks super 1.2 [2/2] [UU]
      
unused devices: 

Прервать такую проверку можно так:

# echo idle > /sys/block/md1/md/sync_action

После чего можно проверить, что массив действительно перестал проверяться:
# cat /proc/mdadm
Personalities : [raid1] 
md1 : active raid1 sdb2[0] sda2[1]
      1911569360 blocks super 1.2 [2/2] [UU]
      
md0 : active raid1 sdb1[0] sda1[1]
      41941944 blocks super 1.2 [2/2] [UU]
      
unused devices:  

Чтобы отменить такую проверку в будущем, нужно установить параметр AUTOCHECK=false в /etc/default/mdadm

Оригинал статьи:
https://blog.tataranovich.com/2012/04/mdadm.html

вторник, 22 мая 2018 г.

Заметка для рейд1 xen 7.x и XCP-NG 
по мотивам копипаста и исправления ошибок в мануалах.
базовая таблица диска поле установки xen 7.x, без созданного на стадии установки локального хранилища
/ (root) 18GB
(update) 18GB
/boot/efi 512M
/var/log 4GB
swap 1GB

0. Удаляем старое


Первым делом отключаем существующие хранилища (если есть):

xe sr-list
xe pbd-list sr-uuid=
xe pbd-unplug uuid=
xe sr-forget uuid=

естественно, pv и vg указываем свои, т.е. после знака равно можно использовать "TAB"

Теперь останавливаем и удаляем RAID, если они есть в системе:
mdadm --stop /dev/md0
mdadm --stop /dev/md1
mdadm --stop /dev/md2
mdadm --stop /dev/md3
mdadm --stop /dev/md4
mdadm --stop /dev/md5

mdadm --zero-superblock /dev/sdb1
mdadm --zero-superblock /dev/sdb2
mdadm --zero-superblock /dev/sdb3
mdadm --zero-superblock /dev/sdb4
mdadm --zero-superblock /dev/sdb5
mdadm --zero-superblock /dev/sdb6

скорее всего их нет либо есть но с другими параметрами
для просмотра состояния делаем:

cat /proc/mdstat

и останавливаем/удаляем существующие

Ниже я считаю, что раздела /dev/sda4 у вас нет.

1. Строим новое


Удаляем таблицу разделов на /dev/sdb и копируем её с /dev/sda:

sgdisk --zap-all /dev/sdb
sgdisk -R /dev/sdb /dev/sda

Задаем тип RAID для разделов:

sgdisk --typecode=1:fd00 /dev/sdb
sgdisk --typecode=2:fd00 /dev/sdb
sgdisk --typecode=3:fd00 /dev/sdb
sgdisk --typecode=5:fd00 /dev/sdb
sgdisk --typecode=6:fd00 /dev/sdb

Создаем, собственно, RAID:

yes|mdadm --create /dev/md0 --level=1 --raid-devices=2 --metadata=0.90 /dev/sdb1 missing
yes|mdadm --create /dev/md1 --level=1 --raid-devices=2 --metadata=0.90 /dev/sdb2 missing
yes|mdadm --create /dev/md2 --level=1 --raid-devices=2 --metadata=0.90 /dev/sdb3 missing
yes|mdadm --create /dev/md3 --level=1 --raid-devices=2 --metadata=0.90 /dev/sdb5 missing
yes|mdadm --create /dev/md4 --level=1 --raid-devices=2 --metadata=0.90 /dev/sdb6 missing


Создаем новый раздел подкачки. Он не будет жить на RAID, поэтому у нас их будет два.
mkswap /dev/md4


Создаем разделы (корень и /var/logs) и монтируем:
mkfs.ext3 /dev/md0
mkfs.ext3 /dev/md3
mount /dev/md0 /mnt
mkdir -p /mnt/var/log
mount /dev/md3 /mnt/var/log

Копируем файлы на новый раздел:

cp -xR --preserve=all / /mnt

Создаем файл mdadm.conf:

echo "MAILADDR root" > /mnt/etc/mdadm.conf
echo "auto +imsm +1.x -all" >> /mnt/etc/mdadm.conf
echo "DEVICE /dev/sd*[a-z][1-9]" >> /mnt/etc/mdadm.conf

mdadm --detail --scan >> /mnt/etc/mdadm.conf
cp /mnt/etc/mdadm.conf /etc


2. Правим fstab и grub



Изменяем точки монтирования на RAID:
sed -i 's/LABEL=root-[a-zA-Z\-]*/\/dev\/md0/' /mnt/etc/fstab
sed -i 's/LABEL=swap-[a-zA-Z\-]*/\/dev\/sda6 md4/' /mnt/etc/fstab
sed -i 's/LABEL=logs-[a-zA-Z\-]*/\/dev\/md3/' /mnt/etc/fstab
sed -i '/sda6/ a\/dev/sdb6          swap      swap   defaults   0  0 ' /mnt/etc/fstab


Копируем метку раздела на /dev/sdb:
e2label /dev/sda1 |xargs -t e2label /dev/sdb1


Делаем chroot в нашу будущую систему:
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
mount --bind /run /mnt/run
chroot /mnt  /bin/bash


Устанавливаем загрузчик:
grub-install /dev/sdb

груб начнет ругатся, исправление:
parted /dev/sdb set 3 bios_grub on

(или grub-install /dev/sdb но перед входом в chroot)

и обновляем мбр/жпт   partprobe
Создаем новый initrd:
Внимание! В большинстве мануалов, строка для дракута немного длиннее, т.к. все скопипищено с аналогичного мануала xen 6x
в результате дракут не отрабатывает как положено.
dracut -q --mdadmconf --fstab --add="dm mdraid" --add-drivers="raid1 raid10" --force /boot/initrd-$(uname -r).img $(uname -r) -M




Меняем конфигурацию GRUB, чтобы загрузиться с RAID:
sed -i 's/quiet/rd.auto rd.auto=1 rhgb quiet/' /boot/grub/grub.cfg
sed -i 's/LABEL=root-[a-zA-Z\-]*/\/dev\/md0/' /boot/grub/grub.cfg
sed -i '/search/ i\   insmod gzio' /boot/grub/grub.cfg
sed -i '/search/ i\   insmod part_msdos' /boot/grub/grub.cfg
sed -i '/search/ i\   insmod diskfilter mdraid09' /boot/grub/grub.cfg
sed -i '/search/ c\   set root=(hd0,gpt1)' /boot/grub/grub.cfg


Выходим из chroot:
exit

////////Запрашиваем КВМ

Перезагружаемся. В качестве загрузочного диска ставим второй, на котом мы создали RAID. Если что-то пойдет не так — будет шанс загрузиться со «старой» системы и попробовать еще раз.

Если всё прошло удачно, то переписываем таблицу с /dev/sdb на /dev/sda:
sgdisk -R /dev/sda /dev/sdb


И добавляем разделы в RAID:
mdadm -a /dev/md0 /dev/sda1
mdadm -a /dev/md1 /dev/sda2
mdadm -a /dev/md2 /dev/sda3
mdadm -a /dev/md3 /dev/sda5
mdadm -a /dev/md4 /dev/sda6


На всякий случай, и переустанавливаем загрузчик на /dev/sda:
grub-install /dev/sda

Перезагружаемся еще раз, дабы проверить, что все установилось корректно.
Ну вот, собственно, и всё. Теперь осталось подключить (или создать) разделы с данными, добавить (если нужно) их в RAID и создать/подключить хранилища:

сначала создаем разделы на sda и sdb, потом рейд, и потом дальше по тексту

xe sr-create content-type=user device-config:device=/dev/md5 host-uuid= name-label=”SRRaid1-Local” shared=false type=lvm

понедельник, 28 августа 2017 г.

Cloud Hosted Router god mode installation
(Установка CHR на любое железо либо VDS)

CHR_VERSION=6.37
INSTALLPATH=/dev/vda

apt-get update &&
apt-get install -y unzip wget pv &&
wget http://download2.mikrotik.com/routeros/${CHR_VERSION}/chr-${CHR_VERSION}.img.zip &&
unzip chr-${CHR_VERSION}.img.zip &&
echo u > /proc/sysrq-trigger &&
pv chr-${CHR_VERSION}.img | dd of=$INSTALLPATH &&
reboot
/user set admin password=********
/ip address add address=A.B.C.D/24 interface=ether1
/ip route add gateway=A.B.C.1
Оригинал на гитхаб https://gist.github.com/deemru/b6ae7e87aed251b727650b360867cfae

четверг, 3 марта 2016 г.

Приоретизация процессов в *nix

Команда nice

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

Команда nice запускает программу с изменённым приоритетом для планировщика задач.

Наибольший приоритет (и наименьшее значение nice) — −20. 19, либо 20 — наименьший приоритет, но это, с другой стороны, самые вежливые процессы.

Чтобы посмотреть идентификатор и значение nice нужного процесса в системе, можно воспользоваться командой ps axl.

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

Чтобы запустить команду с определённым приоритетом, слева нужно добавить «nice -n значение_nice», либо «nice --adjustment значение_nice» (adjustment — настройка, регулировка).

nice -n значение_nice команда.

Если нужно изменить приоритет уже запущенного процесса, можно воспользоваться командой renice.

renice -n значение_nice id_процесса

Команда renice выводит старый и новый приоритет процесса.

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

По материалам https://habrahabr.ru/post/106381/

Ускоряем MySQL

Эта заметка поможет при работе с кривыми скриптами криво работающими с БД MySQL 
( был образец модуля для джумлы который с базой весом в 30 Мб умудрялся наглухо уложить linux-сервер по IOPS дисковой подсистемы)

Ускоряем MySQL с помощью tmpfs
Tmpfs — временное файловое хранилище во многих Unix подобных операционных системах. Tmpfs пердназначена для монтирования файловой системы, а сама размещается в оперативной памяти вместо физического диска. Использование tmpfs в вашей системе можно увидеть с помощью вывода команды df -h
/dev/sda 30G 925M 28G 4%
tmpfs     502M 0 502M 0% /lib/init/rw
udev      497M 60K 497M 1% /dev
tmpfs     502M 4,0K 502M 1% /dev/shm
В tmpfs могут размещатся любые директории, хранящие временные данные и которые можно удалить при перезагрузке системы: /var/lock, /var/run, /tmp и др. Tmpfs используют для уменьшения количества дисковых операций io c целью повышения производительности системы или экономии ресурса твердотельных накопителей.
В процессе работы базы данных MySQL создаются временные таблицы. Место расположения временных таблиц определяется переменной tmpdir в файле /etc/mysql/my.cnf. Если для таких временных таблиц (файлов) не хватает памяти, то начинается активный i/o, создающий нагрузку на дисковую подсистему сервера. А смонтировав папку временных файлов mysql на tmpfs, мы решим проблему проблему производительности базы данных и системы в целом.
На достаточно новых ядрах к директории /dev/shm по умолчанию подмонтирована файловая система tmpfs размером 0,5 объёма физической памяти, которую можно использовать для своих нужд. Если на вашем сервере дело с tmpfs обстоит именно так, нам остается внести правки файл конфигурации MySQL:
$ nano /etc/mysql/my.cnf
Закомментировав предыдущее значение параметра tmpdir, добавляем:
tmpdir = /dev/shm
Перезапускаем базу данных mysql:
$ service mysql restart
Проверяем полученный результат:
$ mysql
mysql> SHOW VARIABLES LIKE 'tmpdir';
+---------------+----------+
| Variable_name | Value    |
+---------------+----------+
| tmpdir        | /dev/shm |
+---------------+----------+
1 row in set (0.00 sec)


Источник: http://serveradministrator.ru/mysql/mysql-to-tmpfs/

понедельник, 29 июня 2015 г.

Рекурсивная смена владельца и группы в *nix

Ключ -R в Linux означает рекурсивную обработку папок и подпапок.
Рекурсивная смена владельца и группы в *nix:

chown -R user:group /home/user/dir/

Если вам нужно рекурсивно поменять права только для папок или только для файлов, то пользуемся следующими командами:

Для папок:
find . -type d -exec chmod 755 {} \;
Для файлов:
find . -type f -exec chmod 644 {} \;

воскресенье, 4 августа 2013 г.

Создание ISO библиотеки в XCP 1.6

How to create a local ISO Storage Repository on Citrix XenServer

In order to create virtual machines based on ISO disks, you need a local ISO Storage Repository on Citrix XenServer. There are several options of ISO Storage repositories in Xen Server based on the location of the repository. You should check the location based on the available space and your space requirements. We recommend to pass:
df -h
before choosing the location. Please be aware that sometimes LVM and the Local Storage do not appear in df -h as they do not have a fstab entry. However, you can see it inside XenServer.
Inside the main partition
(this is least disearable option as the available space is very small, however it is the easiest to be done)
1. Create the directory “/var/opt/xen/iso_library/”
mkdir -p /var/opt/xen/iso_library
2. Create the ISO storage repository with the following command
xe sr-create name-label ="ISO Repository" type=iso device-config:location=/var/opt/xen/iso_library/ device-config:legacy_mode=true content-type=iso
3. Transfer your ISO image in /var/opt/xen/iso_library/ with wget or FTP.
4. Login in Citrix XenCenter and you will now see the new repository. Press Rescan to refresh the images inside.
Inside the Local Storage
If you want to create an local ISO repository inside the Local Storage on Citrix you can use:
xe sr-create name-label=ISO type=iso device-config:location=LOCATION device-config:legacy_mode=true content-type=iso
where LOCATION can be your Local Storage. You can find it out with:
df -h
Inside the LVM
1. Check the free space inside LVM
pvscan
It will output something like this:
PV /dev/sda3 VG VG_XenStorage-10307bc6-dc3b-6b46-b01a-b9efa6f39ae6 lvm2 [1.99 TB / 1.94 TB free]
Total: 1 [1.99 TB] / in use: 1 [1.99 TB] / in no VG: 0 [0 ]

2. Create LVM Space for ISO Repository
lvcreate -L 50G -n ISO VG_XenStorage-10307bc6-dc3b-6b46-b01a-b9efa6f39ae6
(replace the VVG… with your date from pvscan)
and make it active
vgchange -a y
3. Format the new space:
mkfs.ext3 /dev/VG_XenStorage-10307bc6-dc3b-6b46-b01a-b9efa6f39ae6/ISO
4. Mount the ISO Repository
mkdir /mnt/iso_import
and edit /etc/rc.local to put auto mount on boot (do not add it into /etc/fstab!). Add the following text at the end of the file.
[...]
# Mount ISO
vgchange -a y
mount /dev/VG_XenStorage-10307bc6-dc3b-6b46-b01a-b9efa6f39ae6/ISO /mnt/iso_import/

5. Create the following softlink
rmdir /var/opt/xen/iso_import
ln -s /mnt/iso_import /var/opt/xen

6. Create the the repository
xe sr-create name-label=ISO type=iso device-config:location=/mnt/iso_import/ device-config:legacy_mode=true content-type=iso
7. Reboot to be sure that all works fine
8. Transfer your ISO image in /var/opt/xen/iso_library/ with wget or FTP.
9. Login in Citrix XenCenter and you will now see the new repository. Press Rescan to refresh the images inside.

оригинал: http://kb.softescu.ro/server-administration/linux-server-administration/how-to-create-a-local-iso-storage-repository-on-citrix-xenserver/