Если честно даже не понимаю, как я к своим годам так и не заюзал такой супер-удобный инструмент как SSH туннели и проброс портов…

Началось с того, что мне понадобился доступ к удалённой БД, порт снаружи закрыт.
Попробовал настроить SSH туннелирование в настройках БД в PHPStorm …
При тестировании соединения в ssh всё ОК, тест проходит успешно а непосредсвенно при тестировании соединения к БД ругается на то, что не может создать ssh туннель
SSH tunnel creation failed: Connection refused.
Победить так и не смог — хз чего ему не нравится 🙁

Собственно, сразу решение — запускаю с ком.строки (Ubuntu)

ssh -L 3307:localhost:3306 root@SERVER_IP -p SERVER_SSH_PORT -N

и вуаля — цепляемся любым софтом по работе с БД локально на 3307 порт

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

Источник SSH туннели и проброс портов

Частенько при повторном запуске ноды проект запускается на порте отличном от 3000 (вывалилась по ошибке или ещё что).
Это подбешивает если честно, т.к. все ссылки заточены на 3000

вот такой командой можно освободить порт
fuser -k -n tcp 3000

а так создать альяс, чтоб в следующий раз с ком.строки вызывать kill3000
alias kill3000=»fuser -k -n tcp 3000″

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

Увеличение swap

Последнее время начал жестско подвисать локльная станция с ОС Ubuntu — подозрения пали на своп (и не зря).

смотрим что сейчас
#free -h
#top
или в системном мониторе

Отключаем и удаляем этот файл подкачки следующими командами:
#sudo swapoff -a
#sudo rm -f /swapfile
На диске должно быть достаточно места, чтобы туда поместился файл подкачки того размера, который вы задали.

Для создания файла подкачки размером 8G (измените значение по вашему желанию) выполните команду:
#sudo fallocate -l 8G /swapfile
Затем выполните команды:
#sudo chmod 600 /swapfile
#sudo mkswap /swapfile
#sudo swapon /swapfile

Ребутимся — проверяем

https://zalinux.ru/?p=2432

Ускорение ssh соединения

#vi /etc/ssh/sshd_config
Находим строку:

#UseDNS yes
И приводим ее к следующему виду:
UseDNS no

https://www.dmosk.ru/miniinstruktions.php?mini=ssh-slow

Ускорение запуска mc

#hostname
centos.local

После этого добавляем в /etc/hosts:

127.0.0.1 centos.local
Теперь MC запускается мгновенно.

https://serveradmin.ru/ochen-dolgo-zapuskaetsya-mc/

Если Вы при работе с PHPStorm (я работаю в Ubuntu) получили предупреждение

External file changes sync might be slow
The current inotify(7) watch limit is too low. More details.

(Если Вы используете синхронизацию файлов с помощью rsync — Вам так же следует изменить данные параметры ядра)

Вам необходимо увеличить параметр ядра
fs.inotify.max_user_watches
Максимальное количество файлов и директорий, за которыми может наблюдать один объект inotify.

посмотреть текущее значение можно выполнив с консоли
sysctl -a | grep fs.inotify.max_user_watches
у меня текущее значение было 65536

Далее согласно документации добавляем в /etc/sysctl.conf строчку
fs.inotify.max_user_watches = 524288 (в статье ниже тут рекомендую поставить 16777216 но я пока остановился на 524288 — думаю phpstorm-у будет достаточно)
и выполняем в консоли
sudo sysctl -p —system

Вуаля!

Согласно статье Cкоростная синхронизация миллиарда файлов
нужно ещё один параметр «подкрутить»
max_queued_events — максимальное число событий в очереди; default = 16384;

Офф.документация
https://youtrack.jetbrains.com/articles/IDEA-A-2/Inotify-Watches-Limit-Linux

Удобная штука — ssh авторизация по ключу, но на одном из вирутальных серверов почему-то никак не авторизовалось — server refused our key putty

В CentOS логи тут /var/log/secure
Authentication refused: bad ownership or modes for directory /home/bitrix

Меняю на 700 и вуаля!

PS
Везде пишут только про права непосредственно на ~/.ssh/ — оказывается на домашнюю папку тоже нужно!

Вообще, на сервере примерно вот так оно должно выглядеть: (id_rsa.pub — публичный ключ клиенской машины)
mkdir -p ~/.ssh && cat id_rsa.pub >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

Либо сразу с клиентской машины ssh-copy-id user@server — так ключ сразу скопируется в authorized_keys

Плюс в папке /etc/ssh/ файл настройки сервера sshd_config
Обратить внимание чтобы путь до ключей был .ssh/authorized_keys а не ~/.ssh/authorized_keys т.к. демон запускается от рута!

Видимо с завтрашнего дня уже фрилансить по проекту с веб студией, писать буду реже …

Итак, продолжаю заполнять пробелы необходимые для командной работы над проектом.
Вчера тестировал GitLab — информации в любом виде куча, но у меня как обычно — не всё ладно 🙂

Регнулся на гитлабе, завёл пару учёток для совместной работы над тестовым проектом.
С рабочего компа под Win10 всё без проблем как в учебнике.
А вот под виртуальной машиной Битрикс (CentOS 7) при попытке клонировать приватный проект — даёт ошибку

ssh_exchange_identification: read: Connection reset by peer
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Порядок действий делаю как на винде — сгенерил ключ, добавил в gitlab. Пытаюсь клонировать — облом.
Читать полностью »

Работая по ssh зачастую путаешься — то ли ты с правами root то ли под обычным пользователем, отсюда бывают накладочки.
Лично я в ssh предпочитаю работать в файловом менеджере Midnight Commander, поэтому решил для root изменить цветовую схему программы.

Все скины тут /usr/share/mc/skins/
Меняем в конфиге vi ~/.config/mc/ini
(режим вставки i (правим) потом Esc :wq — выйти и записать )
Замена в строке skin=default => skin=darkfar

Менять нужно именно внешним редактором, т.к. если это сделать в самом mc — при выходе он перезаписывает конфиг, соответственно изменения теряются

В некоторых версиях сменить можно интерактивно
Настройки -> Оформление

Но в моём CentOS 7 такой настройки не было

Ранее в систему под управлением CentOS 7 был добавлен жестский диск, ранее использовавшийся в другом компьютере так же под управлением Linux CentOS.
Основной раздел был добавлен в систему просто посмотреть что там было (может что-то пригодиться).
Идея — выделить всё свободное место на этом жестком диске под сайт размещающийся на этом сервере http://dekorimage.ru/

Реализация плана будет такова:
1. Сбор информации — как называется диск, какие на нём разделы, что уже замаплено
2. Размапливаем что есть, удаляем разделы
3. Создаём новые

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

#ls -l /dev/ | grep sd
смотрим все девайсы, отбираем по вхождению sd

lsblk
так же смотрим девайсы, созданные разделы

df –h
информация по разделам

mount
смотрим что уже замонтировано

В моём случае имеем жестский диск
/dev/sdd
и разделы
/dev/sdd1
/dev/sdd2
/dev/sdd3

Третий раздел у меня был замонтирован в /etc/fstab — эту строчку пока закомментируем
больше никаких точек монтирования я не нашел.

Приступаем к удалению имеющихся разделов и созданию нового

parted -a optimal /dev/sdd (параметр -a optimal я добавил т.к. без него чего то там система ругалась на оптимальность распределения места, с ним не ругается)
Вводим команду mklabel
вводим метку диска — msdos или gpt (gpt поновее — я выбрал её)
далее создаём один раздел выделяя под него всё свободное пространство диска
(parted) mkpart primary 0% 100%
для проверки
(parted) align-check opt 1
(parted) align-check min 1
Если выравнивание в порядке, в ответ каждая команда вернет сообщение: «1 aligned».

Создаю файловую систему ext4
mkfs -t ext4 /dev/sdd1

монтирую новый диск
mount /dev/sdd1 /disk3

в папке /disk3 появился папка /lost+found — значит диск замонтировался

так же можно проверить наличие раздела вышеуказанными утилитами (lsblk, df -h)

размонтирую обратно
umount /disk3

Далее — вношу правки в /etc/fstab для монтируемого диска /dev/sdd1
Перезагружаюсь shutdown –r now

Всё!

Для одного из проектов на виртуальной машине 1С Битрик понадобилось включить расширение pdo_sqlite
Как обычно — залез в /etc/php.d/ нашел нужный мне файл 30-pdo_sqlite.ini и переименовал 30-pdo_sqlite.ini.disabled в 30-pdo_sqlite.ini

Расширение не включилось — посмотрел phpinfo() — сам файл 30-pdo_sqlite.ini подцепляется, но сама информация по pdo_sqlite не подключилась
php —ini так же подтвердило подключение модуля

далее решил глянуть инфу с консоли
php -i | grep mysql

тут то в самом начале и обнаружилась проблема

PHP Warning: PHP Startup: Unable to load dynamic library ‘pdo_sqlite’ (tried: /usr/lib64/php/modules/pdo_sqlite (/usr/lib64/php/modules/pdo_sqlite: cannot open shared object file: No such file or directory), /usr/lib64/php/modules/pdo_sqlite.so (/usr/lib64/php/modules/pdo_sqlite.so: undefined symbol: php_pdo_unregister_driver)) in Unknown on line 0

посмотрел — всё Ок, файл /usr/lib64/php/modules/pdo_sqlite присутствует!

В общем не буду томить, решение оказалось очень простым — включение модуля 30-pdo.ini необходимого уже для дальнейшей работы других pdo_*** модулей

Итак — присылает клиент приватный ключевой файл и файлы сертификата (сам сертификат, корневой и промежуточный), задание — прикрутить к nginx и настроить https
Делаю всё как обычно — нифига! nginx валит ошибку и всё тут, хоть убейся

nginx: [emerg] SSL_CTX_use_PrivateKey(«/etc/nginx/ssl/site.key») failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)

Уже всяко разно перепробовал, всё перепроверил — нихрена!
Ну, что — думаю нужно как то проверить валидность этих двух файлов, а точнее проверить их на совместимость.

Быстренько загуглил и вот решение:

openssl x509 -noout -text -in [path of public key]
openssl rsa -noout -text -in [path of private key]

Если поля «MODULUS» и «PUBLIC EXPONENT» совпадают для каждого из ключей, то и сами ключи соответствуют паре.

В случае, если поля не совпадают, вероятнее всего, Вы используете неверный приватный ключ.
Решений здесь может быть несколько, вот, некоторые из них:
1. Попробовать найти верный приватный ключ и повторить попытку;
2. Сгенерировать новый CSR запрос с новым приватным ключом и отправить запрос на перевыпуск сертификата.

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

минус два часа рабочего времени из за косорукости заказчика 🙁