Debian sys maint что это

Обновлено: 08.07.2024

Taking over a Debian Etch web server with MySQL running.

I usually start, stop and restart msyql using:

For some reason on this set up I get the following:

The mysql process is running fine:

I'm sure there are some really easy way to do it but I want to understand what is going on as well. Why is the typical way not working for me?

EDIT UPDATE as an update:

mysqladmin shutdown does work but i'm still curious why the /etc/init.d/mysql commands aren't working.

571 1 1 gold badge 9 9 silver badges 20 20 bronze badges

11 Answers 11

should work to shutdown the server.

I see two likely possibilities:

  1. MySQL has a problem and is refusing to shut down for some reason.
  2. The previous admin did something strange. Either modified the init.d script or didn't bother using the Debian packages at all to install MySQL.

What does dpkg --list mysql\* say?

What does /var/log/mysql.err say? Or the other mysql logs?

EDIT:

So mysqladmin shutdown worked?

According to that, the mysql-server package is installed (mysql-server-5.0; the mysql-server package is probably just a stub). So they may have installed over it? Running debsums mysql-server-5.0 might tell you more. dpkg --listfiles mysql-server-5.0 could help, too.

What's actually in /etc/init.d/mysql? I haven't checked that specific version of the package, but it should try to use mysqladmin shutdown . Maybe you're lucky and they only broke that.


14k 1 1 gold badge 43 43 silver badges 69 69 bronze badges somebody used a Debian package once, at least. They may have compiled from source and overwrote the actual files, or broke it some other way.

Why this is happening

This is a common problem if you do a mysql import and overwrite the mysql database itself, such as when you might be restoring from a mysqldump -A backup.

This is a good thing: you probably want to back up all your mysql users, permissions, etc -- but it can wreak havoc with things like the debian-sys-maint user used to cleanly shutdown mysql.

Although this new database will possibly change both the root password and the debian-sys-maint password, of course it won't automatically change the expected debian-sys-maint password in /etc/mysql/debian.cnf. In fact, unless you also backed up that file, you probably don't even know what that password is anymore!

Resetting the mysql root password (optional)

First things first. If the mysql root password was different between old and new servers, you can use mysqladmin to fix it:

However, when you apt-get installed mysql-server, it probably prompted you for the new mysql root password and you probably used the same one that you were using from before.

Fix the debian sys maint password.

So now look up the debian sys maint password that debian created for you when you installed it on the new server. (You need sudo because this should be a highly protected file.)

Now, log in to mysql using the root password you set above:

Reset the password for the debian-sys-maint user and don't forget to flush privileges:

Меня несколько раз укусил пользователь 'debian-sys-maint', который установлен по умолчанию в пакетах mysql-server, установленных из репозиториев Ubuntu.

Если по какой-либо причине мы добавим новых пользователей mysql, мне придется «объединить» их в мою среду разработки, а не просто наложить таблицу.

Без пользователя моя система все еще кажется работоспособной, но страдает от таких ошибок, как:

  • Для чего используется debian-sys-maint?
    • Есть ли лучший способ для сопровождающих пакетов сделать то, что они пытаются сделать?
    • Похоже, плохая идея «предоставить все привилегии на *. * . »

    редактировать

    Дополнительный вопрос - пароль в /etc/mysql/debian.cnf уже хеширован или это открытый текст? Это имеет значение, когда вы идете воссоздать пользователя, и я, кажется, никогда не понимаю это правильно с первой попытки.

    Пароль в виде открытого текста в /etc/mysql/debian.cnf

    Для чего используется debian-sys-maint?

    Одна из главных вещей, для которой он используется, - указание серверу накатывать логи. Для этого требуется как минимум привилегия перезагрузки и завершения работы.

    Смотрите файл /etc/logrotate.d/mysql-server

    Используется /etc/init.d/mysql сценарием для получения статуса сервера. Он используется для корректного выключения / перезагрузки сервера.

    Вот цитата из README.Debian

    Какой самый простой способ восстановить его после того, как я его потерял?

    Лучший план - просто не потерять его. Если вы действительно потеряли пароль, сбросьте его, используя другую учетную запись. Если вы потеряли все привилегии администратора на сервере MySQL, следуйте инструкциям по сбросу пароля root, а затем восстановите debian-sys-maint .

    Вы можете использовать команду, подобную этой, для создания файла SQL, который вы можете использовать позже для воссоздания учетной записи.

    Пароль в /etc/mysql/debian.cnf уже хэширован

    «Лучший план - просто не потерять его». Шутки в сторону? Это ноль помощи для людей, которые уже потеряли его, как я, очевидно, сделал во время обновления. Для тех, кому нужно заново создать пользователя, используйте один из вариантов «GRANT ALL» в других ответах, потому что этот пользователь НЕ используется только для операций logrotate - это важная часть процесса обновления. Если вы теряете учетные данные, у вас всегда есть возможность, просто запустить демон mysql / mariadb с опцией, которая пропускает систему разрешений, или войти в систему как другой пользователь с привилегиями root для mysql и сбросить пароль. Сброс паролей и обход системы привилегий хорошо задокументированы в других местах в Google и других вопросах на этом сайте.

    Пользователь debian-sys-maint по умолчанию является корневым эквивалентом . Он используется некоторыми сценариями обслуживания в системах Debian и, как побочный эффект, позволяет пользователям с правами root на коробке просматривать открытый текстовый пароль в /etc/mysql/debian.cnf (хорошо или плохо?)

    Вы можете заново создать пользователя:

    Просто убедитесь, что пароль соответствует этому в /etc/mysql/debian.cnf

    Re (хорошо или плохо) - если кому-то удается стать пользователем root, он может полностью обойти систему привилегий, просто перезапустив сервер с правильными параметрами. Если вы, злоумышленник, получите root, у вас, вероятно, больше проблем, чем у этого файла конфигурации. Натан, спасибо за эту ссылку. Это новая информация для меня. Если у вас есть процедура полного отключения учетной записи debian-sys-maint, почему бы вам не включить ее здесь как отдельный ответ? Это было бы прекрасно! лучший грант - просто дать привилегии завершения работы / запуска.

    Вы также можете:

    Что даст вам возможность воссоздать пользователя debian-sys-maint. Существующие пользователи и базы данных в безопасности.

    Это будет работать только в том случае, если установка вашего mysql-сервера не нарушена - что может произойти, если отсутствует пользователь debian-sys-maint.

    Я хотел просто прокомментировать, но я думаю, что правильный синтаксис заслуживает отдельной записи. Это создаст пользователя debian-sys-maint :

    Если у вас все еще есть файл /etc/mysql/debian.cnf, просто используйте там пароль.

    Не стесняйтесь придумать более безопасное решение для параноиков .

    Это настолько параноидально, насколько это необходимо. Тогда только тот, кто сможет прочитать /etc/mysql/debian.cnf файл, является root пользователем Linux . И когда кто-то может прочитать этот файл, он уже имеет root доступ к компьютеру и может остановить сервер MySQL и добавить своего системного администратора. И сценарий, запускающий MySQL и другие пакеты, не может выполнять обслуживание безопасности и другое обслуживание. Так что да, это настолько безопасно, насколько это необходимо. И полезно, если вы потеряете пароль администратора MySQL для его восстановления, без необходимости перезапускать его в небезопасном режиме. ;-)

    Если вам нужно добавить debian-sys-maint пользователя только для logrotate.d целей, вы не должны предоставлять ALL PRIVILEGES или GRANT OPTION - это ненужная гигантская дыра в безопасности. Вместо этого вы можете просто добавить пользователя с такой RELOAD привилегией (при условии, что вы обращаетесь к своей базе данных как root , и вы заменяете xxxxxx своим паролем)

    2019 Обновление

    Этот ответ может быть устаревшим - см. Комментарии со строгим мнением ниже.

    Это единственный безопасный ответ, который дает только необходимые разрешения debian-sys-maint . Кроме того, я могу подтвердить, что это работает как шарм. Ура! Это действительно дыра в безопасности? Если кто-то уже может прочитать /etc/mysql/debian.cnf, то он, по-видимому, имеет root-доступ и в любом случае может перезапустить mysql с --skip-grant-tables. И это не будет работать, так как debian-sys-maint пользователь также используется для выключения сервера. А также для проверки пользователей root при запуске сервера mysql. Поэтому вам по крайней мере необходимо предоставить привилегии select для mysql. * И привилегии завершения работы. НЕТ НЕТ НЕТ, НЕ следуйте советам этого ответа - вам нужно предоставить все права доступа к debian-sys-maint по причинам, изложенным в другом ответе под названием «debian-sys-maint требуемые разрешения». Короче говоря, вы можете быть в порядке в повседневной жизни, но столкнетесь с серьезными проблемами при установке обновления безопасности, исправления или обновления системы.

    потому что пароль не хешируется .

    debian-sys-maint необходимые разрешения

    Сопровождающий Debian не давал капризным пользователям все привилегии. Вот что требуется, где и почему. Некоторые из этих привилегий являются надмножествами других, но я перечислю их независимо, на случай, если вы захотите что-то настроить и отменить требования к ним:

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

    Если mysql_upgrade обнаруживает, что таблица имеет возможную несовместимость, он выполняет проверку таблицы и, если обнаруживаются проблемы, пытается восстановить таблицу.

    ПРЕДУПРЕЖДЕНИЕ. Если вы решили сократить привилегии, которыми обладает debian-sys-maint, то убедитесь, что вы готовы вручную обрабатывать любые будущие обновления безопасности Debian и / или обновления, которые касаются MySQL. Если вы выполняете обновление пакетов MySQL с ограниченными привилегиями debian-sys-maint, и если mysql_upgrade не может завершиться в результате, он может оставить вашу базу данных в неопределенном состоянии (чтение прервано). Снижение привилегий может не вызывать каких-либо очевидных повседневных проблем до тех пор, пока не появится обновление, поэтому не стоит полагать, что вы уже уменьшили привилегии без каких-либо вредных воздействий, поскольку это основание полагать, что это безопасно.

    I have been bitten several times by the 'debian-sys-maint' user that is installed by default on the mysql-server packages installed from the Ubuntu repositories.

    If we add new mysql users for whatever reason, I have to 'merge' these into my development environment as opposed to just overlaying the table.

    Without the user my system still seems functional, but plagued with errors such as:

    • What is debian-sys-maint used for?
      • Is there a better way for the package maintainers to do what they're trying to do?
      • Seems like poor idea to 'grant all privileges on *.* . '

      Edit

      Additional question - Is the password in /etc/mysql/debian.cnf already hashed or is this the plaintext password? It matters when you go to recreate the user and I never seem to get it right on the first try.

      52.9k 31 31 gold badges 130 130 silver badges 206 206 bronze badges 1,759 3 3 gold badges 18 18 silver badges 17 17 bronze badges

      9 Answers 9

      What is debian-sys-maint used for?

      One major thing it is used for is telling the server to roll the logs. It needs at least the reload and shutdown privilege.

      See the file /etc/logrotate.d/mysql-server

      It is used by the /etc/init.d/mysql script to get the status of the server. It is used to gracefully shutdown/reload the server.

      Here is the quote from the README.Debian

      What is the easiest way to restore it after I've lost it?

      The best plan is to simply not lose it. If you really lose the password, reset it, using another account. If you have lost all admin privileges on the mysql server follow the guides to reset the root password, then repair the debian-sys-maint .

      You could use a command like this to build a SQL file that you can use later to recreate the account.

      Is the password in /etc/mysql/debian.cnf already hashed

      127k 37 37 gold badges 266 266 silver badges 411 411 bronze badges If you do lose the credentials, you always have the option, of just starting the mysql/mariadb daemon with the option that skips the permissions system, or logging in as another user with root mysql privileges and resetting the password. Resetting passwords, and bypassing the privilege system is well documented in other locations on Google and other questions on this site.

      The debian-sys-maint user is by default a root equivalent. It is used by certain maintenance scripts on Debian systems, and as a side-effect, allows users with root access on the box to view the plaintext password in /etc/mysql/debian.cnf (good or bad?)

      You can re-create the user by:

      Just make sure the password matches that in /etc/mysql/debian.cnf

      21.7k 19 19 gold badges 67 67 silver badges 102 102 bronze badges Re (good or bad) - If someone manages to become root they can bypass the privilege system entirely by simply restarting the server with the correct options. If you an attacker gets root, you probably have bigger problems then that configuration file. a better grant would be just to give the shutdown/startup privileges.

      Which will give you the option to recreate the debian-sys-maint user. Existing users and databases are safe.

      This will only work if your mysql-server installation is not broken - as could happen if the debian-sys-maint user is missing.

      I wanted to just comment, but I think correct syntax deserves it's own entry. This will create the debian-sys-maint user:

      If you still have the /etc/mysql/debian.cnf file, just use the password in there.

      Feel free to come up with a more paranoid secure solution.

      1,094 2 2 gold badges 11 11 silver badges 23 23 bronze badges

      If you need to add the debian-sys-maint user just for logrotate.d purposes, you should not grant ALL PRIVILEGES or the GRANT OPTION -- this is an unnecessary giant security hole. Instead, you can just add the user with the RELOAD privilege like this (assuming you are accessing your db as root , and you replace xxxxxx with your password)

      2019 Update

      This answer may be out of date -- please see the strongly opinionated comments below.

      This is the single secure answer at it grants only required permissions to debian-sys-maint . Also, I can confirm that it works like a charm. Cheers! Is it really a security hole? If someone can read /etc/mysql/debian.cnf already, then they presumably have root access, and can restart mysql with --skip-grant-tables anyway. And this will not work, as the debian-sys-maint user is also used to shutdown the server. And also to check for a root users when starting the mysql server. So you at least needs to grant select privileges on mysql.* and shutdown privileges.

      because the password is not hashed .


      debian-sys-maint required permissions

      Other answers have sufficiently addressed everything except the minimum set of permissions that are required for the debian-sys-maint user. Many of the answers here are simply wrong in that respect, and in fact dangerous. Do not reduce debian-sys-maint privileges (including the grant option) without reading and understanding below:

      The Debian maintainer did not give all privileges to the user capriciously. Here is what is required, where and why. Some of these privileges are supersets of others, but I will list them independently in case you want to customize things and remove the requirement for them:

      The last one is, of course, the major requirement for privileges. The man page for mysql_upgrade states that:

      mysql_upgrade examines all tables in all databases for incompatibilities with the current version of MySQL Server. mysql_upgrade also upgrades the system tables so that you can take advantage of new privileges or capabilities that might have been added.

      If mysql_upgrade finds that a table has a possible incompatibility, it performs a table check and, if problems are found, attempts a table repair.

      WARNING If you decide to cut down on the privileges that debian-sys-maint has, then make sure you are prepared to manually handle any future debian security updates and/or upgrades that touch MySQL. If you perform an update on the MySQL packages with a reduced debian-sys-maint privilege, and if mysql_upgrade cannot complete as a result, it may leave your database in an undefined (read broken) state. Reducing privileges may not have any apparent day-to-day issues until an update comes along, so do not go by the fact that you have already reduced privileges with no harmful effects as a basis for thinking it is safe.

      Задача: по включению сервера необходимо автоматически (без вмешательства администратора) гарантированно обеспечить целостность баз данных MySQL .

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

      Способ: синхронная(блокирующая) проверка баз данных с принудительным автоматическим восстановлением найденных повреждённых таблиц, выполняемая по каждому запуску/перезапуску демона mysql.

      Хотя целевой системой для написания статьи предполагаются Debian GNU/Linux или его производные (Ubuntu, Mint, …), по нашему поверхностному мнению, рассмотренное решение легко портируется на другие дистрибутивы Linux или даже другие OS и другие SQL -сервера.

      Реализация.

      Прежде всего нужно проверить систему инициализации (init) вашего дистрибутива, а именно:

      зависимость по запуску: MySuperMajorDaemon должен запускаться после mysqld, а останавливаться раньше; в init-системах с параллельной загрузкой (upstart, initng) нужно запретить параллельный запуск (если конечно такой режим используется) демонов MySuperMajorDaemon от mysql.

      В Debian GNU/Linux 4.0 используется классический sysvint (System-V-like init utilities) в которой init-сценарии демонов из каталога /etc/init.d/ запускаются последовательно и верно, но медленно, поэтому нам остаётся проверить лишь порядок запуска и останова нашего демона, относительно демона mysqld.

      Примечание: в Ubuntu, несмотря на использование «параллельного» upstart вместо классического sysvint, init-скрипты, похоже, также стартуют последовательно.

      Итак, ниже приводим самый низкоуровневый способ проверки, подходящий для большинства дистрибутивов, использующих sysvinit и upstart. Для начала, определим текущий RUNLEVEL.

      Выводим на экран имена скриптов в одну колонку в порядке запуска/останова.

      С порядком порядок ? Тогда двигаемся дальше.

      Теперь куда-то нужно вставить код проверки и лечения баз.
      Таких мест (чтобы было наверняка) всего два:

      Мы выбираем первый вариант и, как оказывается, «всё уже украдено до нас» — нужный нам код уже предусмотрен прямо «из коробки» (из пакета «mysql-server»).

      Часть кода init-сценария запуска демона mysqld

      Как видно из кода, строка « output=$(/etc/mysql/debian-start) » запускает некий исполняемый скрипт « /etc/mysql/debian-start »

      Отлично. Вкратце, скрипт работает так:

      подгружает библиотечный код из /usr/share/mysql/debian-start.inc.sh , в котором описаны функции upgrade_system_tables_if_necessary() и check_for_crashed_tables() ;

      Запуск системы продолжается (загружаются другие демоны), а функции (см. выше) параллельно отрабатывают в фоне и сообщают о результатах своей работы в системный журнал (Syslog) и дополнительно, в случае ошибок, root-y на e-mail.

      Хм, в штатно-предусмотренном сценарии « /etc/mysql/debian-start » нас не устраивают две вещи:

      проверка и восстановление осуществляется в фоне, т.е. при загрузке системы возможен вариант, когда наш демонюга MySuperMajorDaemon запустится на «недолеченных» повреждённых базах и может страшно обидится на это; mysqlcheck , запущенный с дефолтными опциями определёнными в MYCHECK_PARAMS , не будет восстанавливать повреждённые базы, а только лишь найдёт их, запишет об этом в журнал и уведомит root-а.

      патч для debian-start

      Раскроем опции mysqlcheck , выбранные на наш вкус.
      Как убрали фоновую обработку (background), надеемся, понятно.

      Все рассматриваемые скрипты принадлежат deb-пакету mysql-server-5.0

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

      Недостатки.

      К недостаткам решения можно отнести увеличившееся время выполнения скрипта « /etc/init.d/mysql start ». Если базы данных небольшие и целые, то это время вы можете даже не почувствовать. Но если базы приличного объёма и при этом повреждённые, то вы точно успеете сварить кофе или даже сходить пообедать .

      Об этом следует помнить, особенно при удалённой работе с сервером по ssh и особенно при удалённой перезагрузке сервера Debian 4.0 Etch, ибо:

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

      В Убунту с этим делом полегче, сервер SSH запускается раньше MySQL .

      Для сокращения времени проверки и восстановления можно ограничить состав баз данных ( databases ) или даже указать конкретные таблицы ( tables ), но только одной базы данных. Детали смотрите в первоисточнике «mysqlcheck(1)».

      «Магия» debian.cnf

      Особо наблюдательные могут спросить: а как mysqlcheck будет что-то там лечить, ведь для этого он должен знать пароль root-а (mysql-льного, не путать с системным).
      Отвечаем: пароль mysql-ного root-а mysqlcheck не знает, он запускается от пользователя « debian-sys-maint », пароль которого прописан в файле « /etc/mysql/debian.cnf ».

      $ sudo cat /etc/mysql/debian.cnf

      Mysql-пользователь с именем « debian-sys-maint » создаётся при установке пакета mysql-server, пароль для него из 16 знаков генерируется случайным образом. « debian-sys-maint » может почти то же, что и root.

      Теперь опять внимательно посмотрим « /etc/mysql/debian-start »

      Теперь понятно откуда mysqlcheck берёт имя и пароль для работы с сервером?

      Благодаря сохранённому в файле аккаунту « debian-sys-maint » многие Debian/Ubuntu пакеты, использующие базы данных, при установке/обновлении автоматически или после подтверждения пользователя создают/обновляют структуры своих баз. Это один из механизмов «дружественности к пользователю», которым достигается принцип «установил/обновил и сразу работает» принятых(возможных) в пакетной базе дистрибутивов, основанных на Debian.

      Вопросы безопасности.

      Уже слышим брюзжание экспертов в области безопасности .

      Экперты: Как это так, пароль почти root-а (опять напомним, mysql-льного, не путать с системным) сохранён в файле на диске.
      Отвечаем: /etc/mysql/debian.cnf имеет атрибуты доступа 0600 root:root , которые позволяют читать этот файл только одному пользователю в системе - root-у. А если вы профукаете пароль системного root-а, то злоумышленник легко получит доступ с базам и без информации из /etc/mysql/debian.cnf .

      Ну а самым яростным специалистам в области безопасности, советуем вспомнить установлены ли вообще или давно ли менялись пароли root-ов, и системного и mysql-ного

      Немного о «железе».

      Чтобы сервер (компьютер) автоматически запустился после возобновления питания нужно:

      Читайте также: