LINUX.ORG.RU

Как в CentOS/Redhat/Fedora принято создавать базу Mysql при установке пакета

 


0

1

Мне потребовалось создать rpm пакет для CentOS. Пакет при установке должен создавать базу в MySQL. Почитав доки федоры, выяснил, что rpm может (и должен) работать только в не интерактивном режиме (в отличие от дебиана, у которого несколько интерактивных фронтендов и в котором при установке можно задавать вопросы). Далее выяснил, что mariadb-server устанавливается в CentOS с пустым паролем администратора и слушает на 0.0.0.0 (а также, в одном из вариантов он у меня установился с правами 755 на unix сокет mysql, что привело к невозможности подключению через localhost к MySQL нерутовому пользователю). Настройкой MariaDB я заниматься не хочу, т.к. ей может пользоваться не только мой пакет, и такими настройками должен заниматься админ и установочные скрипты mariadb-server.

Теперь я пытаюсь понять, какой у меня должен быть алгоритм работы установочного скрипта пакета, которому нужно создать базу. Как вообще это принято в мире rpm? Пароль администратора (который должен быть установлен) я спросить не могу, сообщить пользователю, что пароль не подходит тоже (это могу, но не факт, что он заметит сообщение). Скрипт должен уметь работать как с только что установленным сервером базы данных (по зависимостям пакета) так и с уже давно установленным и настроенным. Я, пока, додумался лишь до того, чтобы пытаться подключиться без пароля и с использованием того, что написано в ~root/.my.cnf, и если не получится, то сообщать, что нужно создать ~root/.my.cnf и руками запустить скрипт, который подготовит пакет к работе (создаст базу, зальет данные...). (Тут, однако, не понятно, почему при установке Машки, редхатовцы по умолчанию не создают ~root/.my.cnf с админским паролем, ибо пароль должен быть, при неинтерактивной установке его больше девать некуда, а линкусовый рут при необходимости, всегда может запустить Машку в режиме без привелегий, т.е. знание рутом пароля от базы никак не повлияет на его возможности доступа к данным)

Однако, я, наверняка, не первый, кто решает такую задачу (создания базы в установочных скрпитах). Как такое принято делать в федоре-редхате?

Да вроде все пацаны пишут какой-нибудь интерактивный first-time-config.sh, который надо запускать после установки.

thesis ★★★★★ ()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от thesis

Для прожженного админа-слакварщика (или гентушника) вполне сойдет (на самом деле для админа удобнее веб страничка с последовательностью команд шелла, которые он адаптирует под свою систему, тогда в случае ошибки не придется разбираться в каком месте скрипта она произошла).

Мне же нужно сделать систему удобную для пользователя. Установил - и все работает. При этом пакет должен также устанавливаться и на систему, где есть админ, который заадминил все, включая и MariaDB. При этом скрипт установки должен быть разумной сложности и надежности.

traffic ()
Ответ на: комментарий от traffic

А у тебя выбора нет. Либо так, либо пихай все в docker, его для этого и придумали. Или, если приложение гуевое - можно написать отдельный конфигуратор, как для всякой вебни делают.

Мне же нужно сделать систему удобную для пользователя.

Для этого (в данном вопросе) нужно надстраивать менеджер пакетов до полноценной работы с гуями.

thesis ★★★★★ ()

вообще-то программа __не_должна__ создавать SQL баз при собственной инсталляции. Может левой пятке админа хочется чтобы все базы крутились на соседнем сервере, специально под это заточенным. И кстати СУБД(место храненения данных) дело скорее локального пользователя, а не того кто ставит софт на хост.

вот при первом запуске, раз уж без SQL никуда - пусть ругается в системный журанал, диалоговыми окнами и по прочему жестикулирует «дайте базу чтобы развернуться и работать»

MKuznetsov ★★★★★ ()

Как такое принято делать в федоре-редхате?

В цивилизованном мире принято пользоваться fabric, ansible, puppet, chef, <whatever> и не путать теплое с мягким.

alpha ★★★★★ ()
Ответ на: комментарий от traffic

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

не слишком большой и не слишком шаблонизированный ansible playbook выглядит практически именно так

маленький пример:

https://github.com/bookwar/discourse-playbook/blob/master/roles/common/tasks/...

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 1)

/bin/mysql_secure_installation после установки можно. А вообще правильно написали выше про puppet/ansible.

generator ★★★ ()
Ответ на: комментарий от MKuznetsov

вообще-то программа __не_должна__ создавать SQL баз при собственной инсталляции.

В идеальном мире все так, а в реальном пользователь скажет: «Ой, я установил пакет, а у меня ничего не работает.» И завалит форум вопросами или выберет альтернативный продукт.

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

traffic ()
Ответ на: комментарий от MKuznetsov

вот при первом запуске, раз уж без SQL никуда - пусть ругается в системный журанал, диалоговыми окнами и по прочему жестикулирует «дайте базу чтобы развернуться и работать»

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

traffic ()
Ответ на: комментарий от alpha

В цивилизованном мире принято пользоваться fabric, ansible, puppet, chef, <whatever> и не путать теплое с мягким.

Это как. Сказать пользователю, чтобы он сначала осилил fabric, ansible, puppet, chef, <whatever>, а только потом ставил мой софт?

traffic ()
Ответ на: комментарий от alpha

не слишком большой и не слишком шаблонизированный ansible playbook выглядит практически именно так

Мне нужно просто создать базу и залить туда дамп. Зачем мне ansible. Почему бы не сделать это скриптом на bash.

Задача простая. Нужно по умолчанию делать то, что подходит 95-99% пользователей, а если это невозможно, то выводить информативное сообщение об ошибке и предоставить удобный способ вручную проделать необходимое.

traffic ()
Ответ на: комментарий от thesis

либо пихай все в docker

Насколько я понимаю docker придумали по двум причинам. Машины стали мощными до неприличия и разработчиков сильно не хватает (а админов как грязи). В результате разработчик, когда напишет какой-либо софт, который работает только на его машине, чтобы не разбираться, чего ему не хватает на сервере, просто заворачивают всю файловую систему машины разраба вместе с как-то работающим пакетом в образ докера и запускают на сервере. Соответственно владельцу сервера приходится разбираться с докером, потому что разработчику вломы разбираться, почему его софт там не работает. Про обновления вообще принято не думать.

Мне не вломы и я не хочу заставлять пользователя разбираться с докером.

P.S. Отличный пример, почему выгоднее быть разработчиком, чем админом. Админу приходиться разгребать все, что оставил за собой разработчик. Да и денег платят в разы больше. И конкуренция сильно меньше. Но это уже сильный offtop.

traffic ()
Ответ на: комментарий от traffic

Или можно установить Машку по зависимостям, запустить ее, создать в ней базу и

вот с этого момента софт от Васи идёт в помойку. Ибо нефик по зависимостям таскать целые серверные конфигурации.

MKuznetsov ★★★★★ ()

Обычно к приложениям, которым нужна mysql-база, идет инструкция, как руками все настроить и создать.

Ну или если пользователи совсем не алё в этом плане, может смысл использовать sqlite заместо mysql? Если конечно такая возможность есть.

Deleted ()
Ответ на: комментарий от traffic

Мне не вломы и я не хочу заставлять пользователя разбираться с докером.

Садишься и пишешь проверку первого запуска и конфигуратор.

thesis ★★★★★ ()
Ответ на: комментарий от traffic

Осиливать должен не пользователь, а ты. А пользователь должен задать параметры и набрать fabric deploy.

Либо, если он у тебя сервер получает в готовом виде - добавь свою магию в kickstart и распространяй исошку.

А если пользователь ставит кривой софт, который грязными лапами лезет в /root править доступы к mysql, и ставит его на живой сервер, то вас обоих вместе надо выгонять из профессии.

alpha ★★★★★ ()
Ответ на: комментарий от MKuznetsov

Во-первых, на мнение админа при установке софта насрать. Какой софт руководство решит ставить (купить), с таким админ и будет возиться. Админ - IT'шный сантехник, не более.

Во-вторых, как я уже сказал, можешь перенести дамп куда угодно и поправить конфиг.

В-третьих, если тебе нравится при установке любого софта даже на посмотреть копиться в конфигах - твое право. Но не все такие.

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

В-пятых, зависимости тебе покажут ДО установки. Не нравится зависимость от MySQL - не ставь.

traffic ()
Ответ на: комментарий от alpha

Осиливать должен не пользователь, а ты. А пользователь должен задать параметры и набрать fabric deploy.

Пока что ты мне предложил по сути только от конфигурирования скриптом на shell к конфигурированию через fabric. Разницы я не увидел. Софт ставится на единичный сервер, мне не нужно на кластер машин раскатывать один пакет. Это не задача dev-ops.

traffic ()

Пакет при установке должен создавать базу в MySQL

Не должен. Как раз в силу того, что

ей может пользоваться не только мой пакет, и такими настройками должен заниматься админ и установочные скрипты mariadb-server.

К тому же, база в общем случае совершенно не обязана находиться на том же хосте, что и приложение. Не говоря уже о том, что установка с нуля и обновление со старой версии (когда уже есть и база, и конфиг) — не одно и то же.

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

Делается пакет, зависимый от mysql-libs и содержащий (подчеркиваю — не запускающий при установке, а всего лишь содержащий) скрипт, способный подключиться к тому mysql-серверу и с теми учетными данными, с которыми скажет пользователь (по умолчанию — подключается беспарольным рутом к юникс-сокету).

почему при установке Машки, редхатовцы по умолчанию не создают ~root/.my.cnf

А почему при установке mariadb-server должен беспременно создаваться ~root/my.cnf?

разработчиков сильно не хватает (а админов как грязи)

Скорее наоборот — быдлокодеров как грязи, а админов не хватает.

dexpl ★★★★★ ()
Ответ на: комментарий от traffic

bash-скрипт выполняется локально, fabric ходит на удаленный сервер.

Идеологической разницы нет, но playbook на ansible гораздо проще поддерживать за счет достаточно числа встроенных стандартных операций за счет банально читабельности кода см. пример выше.

Главный вопрос не в том на чем писать, а в том, что установка пакета и конфигурация его - разные вещи и должны оставаться такими. У конфигов и пакетов разные жизненные циклы, разные способы хранения, разные зоны ответственности и т.п.

alpha ★★★★★ ()
Ответ на: комментарий от dexpl

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

А теперь представь, что ты пользователь, которому хочется чтобы установил и оно заработало. Вариант со скриптами, которые нужно запускать отдельно отпадает, как и документация, которую надо читать. В моем случае в ~100% случаев софт будет работать с локальной базой, поэтому вполне реально залить пустую базу, и, даже, при наличии старой, обновить ее (если используется более новая версия). Более того, вполне реальный вариант использования, это когда если что-то не работает пользователь сначала удаляет пакет, а потом тут же заново устанавливает (разумеется все данные, должны остаться на месте). В случае повторной установки нужен старый конфиг, а в случае новой админский пароль от базы, либо он должен лежать в .my.cnf.

А почему при установке mariadb-server должен беспременно создаваться ~root/my.cnf?

Не должен, но таким образом mariadb-server сможет установить на базу админский пароль и пользователь root сможет подключаться к базе. Сейчас админский пароль у установленной базы пустой. Какой вариант тебе больше нравится?

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

P.S. Мой софт чужие конфиги не исправляет и, если не может создать нужную базу, то просто выдает ошибку.

traffic ()
Ответ на: комментарий от alpha

Главный вопрос не в том на чем писать, а в том, что установка пакета и конфигурация его - разные вещи и должны оставаться такими. У конфигов и пакетов разные жизненные циклы, разные способы хранения, разные зоны ответственности и т.п.

Ты все тут здорово описал, но для какого-то другого случая. Для задач dev-ops, например. Софт в виде пакетов во всех дистирбутивах пока что распространяется вместе с конфигами.

traffic ()
Ответ на: комментарий от traffic

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

alpha ★★★★★ ()

mysql_install_db && /etc/init.d/mysqld start && mysql_secure_installation

r0ck3r ★★★★★ ()
Ответ на: комментарий от traffic

Я сам был админом

Эникейщиком. Иначе сам понимал бы, что «правильно» — это и есть «удобно».

IMHO <…>

Ты хотел узнать «как принято»? Вот узнал. Кстати, посмотри, как опакечены в Федоре mantis и glpi.

В моем случае в ~100% случаев софт будет работать с локальной базой

Даже интересно стало — что за софт такой у тебя…

когда если что-то не работает пользователь сначала удаляет пакет

…и на кого рассчитан?

Не должен, но таким образом mariadb-server сможет установить на базу админский пароль и пользователь root сможет подключаться к базе. Сейчас админский пароль у установленной базы пустой. Какой вариант тебе больше нравится?

Существующий: mysql'ный рут может подключиться локально к юникс-сокету (и только к юникс-сокету); системный root, если надо будет, выполнит mysql_secure_install.

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

А еще удобнее, когда софт не делает то, о чем его не просят. В частности, создает базу не при установке, а при первом запуске.

dexpl ★★★★★ ()

Как такое принято делать в федоре-редхате?

ЕМНИП, софту, который не работает без конфигурации, положено фейлить при старте с ясным сообщением.

В твоем случае можно сделать отдельный пакеты cattlesoft.rpm, в котором собственно софт, и зависящий от cattlesoft.rpm пакет cattlesoft-local-db, который при инсталляции что-нибудь создает.

tailgunner ★★★★★ ()
Ответ на: комментарий от alpha

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

Это не мой случай. У меня демон.

traffic ()
Ответ на: комментарий от dexpl

далеко не всегда правильно = удобно, ох как далеко не всегда. например правильно поставить свежую freebsd установить всё необходимое, и потом настроить через конфиги, а удобно поставить pfsense и сделать всё через веб морду. и примеров можно приводить ещё много.

erzentded ()
Ответ на: комментарий от traffic

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

Setup.exe, не?

sin_a ★★★★★ ()
Ответ на: комментарий от erzentded

правильно поставить свежую freebsd

Freebsd — это ни в коем случае не правильно.

dexpl ★★★★★ ()
Ответ на: комментарий от dexpl

Кстати, посмотри, как опакечены в Федоре mantis и glpi.

Да, любое ПО которое оказывается в таких условиях. Также cacti (кстати не помню, как у него это реализовано).

sin_a ★★★★★ ()
Ответ на: комментарий от sin_a

Кстати, посмотри, как опакечены в Федоре mantis и glpi.

Да, любое ПО которое оказывается в таких условиях. Также cacti (кстати не помню, как у него это реализовано).

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

Cacti по сути интерактивное приложение, так что там и инсталлятор наверняка есть.

traffic ()
Ответ на: комментарий от traffic

Ты спросил как принято делать. Принято делать правильно.

так что там и инсталлятор наверняка есть

ну-ну, нашел?

P.S.: у тех, кто делает правильно, «зарплата админа» - это не ругательство :)

alpha ★★★★★ ()
Ответ на: комментарий от traffic

Во-первых, на мнение админа при установке софта насрать. Какой софт руководство решит ставить (купить), с таким админ и будет возиться. Админ - IT'шный сантехник, не более.

Еще одна пуся, не осилившая в админы? Нормальное руководство даст нормальному админу выбор и выслушает его мнение, о том, какой ты жопорукий девелопер, и что твой «удобный» высер невозможно ни адекватно установить, ни поддерживать. Далее твой выхлоп идет лесом и руководство покупает адекватный продукт конкурентов, удовлетворяющий элементарному здравому смыслу.

Мне же нужно сделать систему удобную для пользователя. Установил - и все работает.

Ты путаешь пользователя Linux и пользователя систем с setup.exe.

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

Тебе и срать под себя удобно, но ты же почему-то этого не делаешь?

А теперь представь, что ты пользователь, которому хочется чтобы установил и оно заработало.

Чтение элементарного INSTALL.txt еще никто не отменял.

Я сам был админом

Ждем следующий выхлоп под названием «Я сам был девелопером».

разгребай косяки, которые на тебя сваливают разработчики

Тебе еще предстоит разгребать косяки, которые на тебя свалят пользователи твоего говно скрипта установки, который глючить будет через раз, а то и чаще. И всё это на ЗП «разраба», которая отнюдь не «в разы».

anonymous ()
Ответ на: комментарий от alpha

Да чего ты ему объясняешь, дурачок уже показал, что слушать и учиться на чужих ошибках он не намерен, а намерен делать как «удобно» и изобретать лисапед:-)

Таким помогать не нужно. Пусть городит запуск очередной sh-лапши при установке пакета. Будет примером bad practices.

anonymous ()
Ответ на: комментарий от alpha

P.S.: у тех, кто делает правильно, «зарплата админа» - это не ругательство :)

Сравни свою зарплату админа с зарплатой разработчика и поймешь, в каком месте пищевой цепи ты находишься. Очень весело будет сравнивать себя, например, с разработчиком фронтэнда (на них сейчас особо большой спрос).

В сказку, «квалифицированный специалист всегда найдет себе хорошую работу с большой зарплатой» я давно не верю. Потому что работодатели хотят квалифицированного специалиста за зарплату ниже средней. При этом ее уровень определяет спрос и предложение. На рынке сисадминов в избытке, причем достаточно квалифицированных. Поэтому работодатель всегда сможет найти задрота сравнимой с тобой квалификации (так зачем платить больше). В общем без связей в этой сфере денег не заработать, а со связями тебе навыки сисадмина не особо нужны.

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

traffic ()
Ответ на: комментарий от traffic

В хрониках Нарнии, в самой последней части, есть душераздирающая сцена про гномов в хлеву. Вот я когда рассуждения наподобие этих «пищевых цепей» читаю, всё время её вспоминаю.

alpha ★★★★★ ()
Ответ на: комментарий от traffic

А теперь представь, что ты пользователь, которому хочется чтобы установил и оно заработало. ...

В таком случае делай embedded mysql server и не парься. Так сделано в KDE.

TOXA ★★ ()
Ответ на: комментарий от traffic

это идеальный вариант, если не хочешь проклятий от тех, кто уже использует mysql/maria и тех, кто начнет ими пользоваться с твоим продуктом.

Схему при первом запуске выполняешь из файла. В доках пишешь про то, что нужен mysql, где лежат настройки в софтине и где взять схему.

TOXA ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.