Хост машина с Ubuntu 22.04 на ней VMWare Player
после зависона VMWare Player из за переполнения винта — guest CentOs ни в какую не видит сетевой интерфейс
#ifconfig
показывает только lo
#ip a
слава богу видит ens33 но с пометкой unmanaged

нарыл в сети утилитку по настройке — nmtui
вроде всё автоматом поставил, пытаюсь активировать — получаю ошибку

Could not activate connection: Connection ‘ens33’ is not available on device ens33 because device is strictly unmanaged

2 часа мучений и спасительные 3 команды
nmcli n off
nmcli n on
nmcli

вуаля — всё работает!
ребут — всё работат!

вот такая херня на ровном месте

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

Увеличение 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_*** модулей

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

Тем не менее после того, как свежеустановленной windows 10 подключаешь интернет, через некоторое время звук просто перестаёт работать.

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

Откат всех обновлений с помощью майкрософтовкой утилиты так же не дал никаких результатов 🙁

Собственно, помогло только одно решение — с помощью групповых политик, запрет использования Центра обновлений Windows при поиске драйверов.

Запускаем gpedit.msc

Административные шаблоны / Система / Управление связью через Интернет / Параметры связи через Интернет / Отключить использование Центра обновлений Windows при поиске драйверов

Мне помогло, там рядом ещё параметр что-то связанное с запросом — его тоже врубил.

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

Административные шаблоны / Система / Установка устройств / Ограничения на установку устройств / Запретить установку устройств с указанными кодами устройств

Итак — присылает клиент приватный ключевой файл и файлы сертификата (сам сертификат, корневой и промежуточный), задание — прикрутить к 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 запрос с новым приватным ключом и отправить запрос на перевыпуск сертификата.

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

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