Вам нужно будет скопировать сценарий systemd для mysql и назвать его как-нибудь новым, скорее всего, он быть mariadb.service, поэтому вы скопируете его и создадите файл mariadb2.service, а затем отредактируйте файл, чтобы он указывал на ваш второй файл my.cnf.
Эти файлы systemd расположены в / etc / systemd / system /, однако большинство из них являются ссылками на /usr/lib/systemd/system/servicename.service
, после этого вы можете выполнять такие действия, как запуск / остановка службы mariadb2 и systemctl. включить mariadb2.
Ваш первый вопрос ("зачем мне нужен секретный ключ для подписи открытого ключа?" )это просто :так работает шифрование с открытым ключом. При подписании чего-либо (ключа, документа и т. д. )используется ваш закрытый ключ, и это может быть проверено с помощью вашего открытого ключа. Шифрование использует ваш открытый ключ и может быть расшифровано с помощью вашего личного ключа.
Ваш второй вопрос более сложный. Подписание или неподписание ключа не должно иметь значения — подписание только предотвратит предупреждения о том, что ключ не является доверенным; это важная часть сети -из -доверия, на которой построены PGP/GPG. Но если вы проверили правильность ключа вне сети доверия (, например, получив его непосредственно от получателя ), вы можете игнорировать сеть доверия. Так что подпись не нужна.
Я предполагаю, что вы используете аргумент -r
, отличный от полного отпечатка ключа, и вы случайно шифруете не тому получателю. Вы должны использовать полный отпечаток (, например, 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500
, а не короткий EF0F382A1A7B6500
и уж точно не очень короткий1A7B6500
).
Единственная другая вещь, о которой я могу думать, это то, что вы используете (вероятно, не подозревая об этом )какой-то алгоритм, который не поддерживает сторона дешифрования. Например, если вы используете более новую версию gnupg, чем получатель. Или получатель использует какую-то другую программу. Для ключа получателя нормально указать, что поддерживает программа, но, возможно, этот конкретный ключ не поддерживает или он неправильный. В GPG есть варианты переопределения (, см. справочную страницу в разделе «ВЗАИМОДЕЙСТВИЕ», но стоит попробовать --pgp8
, --pgp7
и --pgp6
).
gnupg сообщает, какой ключ требуется для расшифровки файла до того, как произойдет сбой, поскольку он включен в заголовки зашифрованного сообщения. Например:
‰ gpg -d test
gpg: encrypted with 4096-bit RSA key, ID 0xF38153E276D54749, created 2011-09-23
"Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>"
gpg: decryption failed: No secret key
Соответствует ли ключ, указанный в сообщении, какому-либо ключу в выводе gpg --list-secret-keys
на клиенте B? Похоже, вы получили неправильный открытый ключ или клиент Б удалил рассматриваемый секретный {sub,}ключ.