Идентификаторы операционной системы в Linux
Виндовс несет в себе множество идентификаторов операционной системы, которые позволяют узнать конкретный экземпляр ОС — дата установки системы, номер лицензии, VolumeiID, SID, WSUS Client ID, DTC. А есть аналоги в Linux (конкретно — Debian)? Метки конкретного экземпляра ОС, установленного на конкретной машине под конкретным железом. И главное — есть ли источник, в котором можно найти информацию по этому поводу?
Но зойчем, чем мак адрес не устраивает?
Здесь у нас такое не принято, достаточно /etc/os-release.
Вполне может быть почищено какой-нибудь чистилкой логов или вручную. Если дебиан с ненужноД, то есть /etc/machine-id — уникальный (типа, так как там слишком мало символов) иденификатор машины + его можно поменять легко. Так что можно например ориентироватся на макадрес сетевухи. но ее тоже можно вытащить или поменять мак.
Можно идентифицировать машину по серийному номеру винчестера.
Ненужно идентифицировать *глобально*, но для своих нужд — можно настроить /etc/motd и сделать hostname, какое нравится.
И главное — есть ли источник, в котором можно найти информацию
Интернет большой. Вот прямо этот сайт — тоже интернет, имелась ввиду документация, литература, конкретные места компактного проживания нужной информации (не нашел). Опять таки, если не нашел информацию по идентификаторам ОС — то не смогу понять, просто не нашел или их не существует.
В «этих» ОС такое огораживание не практикуется, если тебе по служебным надобностям это надо, то сделай сам, или найми человека который это сделает за тебя.
Как-раз на днях впервые заметил эту штуку. Лоргугл, скажи зачем оно (не)нужно?
Чтобы куратору было проще.
Ну это само собой, я имею в виду какое официальное обоснование
Сходи в википедию по запросу «GUID».
Create a machine ID for journaling to work. This can be done through the following command:
Создайте идентикационный код машины, для журналирования. Это можно сделать следующей командой:
The command systemd-machine-id-setup also has an impact on the systemd-networkd service. If you don’t run this command, strange behavior like network interfaces not coming UP or network addresses not being applied will occur.
Команда systemd-machine-id-setup также влияет на работу systemd-networkd. Если вы не выполните данную команду, то этот сервис будет вести себя непредсказуемо, например сетевые интерфейсы не будут подниматься, или сетевые адреса не будут применены
Источник
- MachineId
What is a machine id
From man 5 machine-id:
- The /etc/machine-id file contains the unique machine ID of the local system that is set during installation or boot. The machine ID is a single newline-terminated, hexadecimal, 32-character, lowercase ID. When decoded from hexadecimal, this corresponds to a 16-byte/128-bit value. This ID may not be all zeros.
That man page has a lot of more information and is a recommended read. In addition, there seems to be a connection between systemd and dbus in this matter, as dbus keeps track of the machine-id as well. The machine id is stored in /etc/machine-id, with the dbus copy of the machine id either symlinked from or copied to /var/lib/dbus/machine-id.
For historical reasons (dbus originated the concept and systemd generalized it into a non-D-Bus-specific «API»), each of systemd-machine-id-setup and dbus-uuidgen tries to copy the other’s machine ID, to avoid problems where processes that read the two files in opposite orders disagree on what the machine’s unique ID is. If you delete or empty /etc/machine-id you should also delete /var/lib/dbus/machine-id.
The machine-id isn’t really particularly specific to either D-Bus or systemd: they both provide it as a piece of generically useful functionality for anything else that wants it. Asking which applications use it is a bit like asking which applications use gethostname(2): you are not going to get an exhaustive list unless you use something like codesearch.
It’s intended as an opaque, non-human-meaningful, persistent unique identifier for a machine (or more precisely an OS installation), used as a lookup key in state/configuration storage in the same sorts of places you might be tempted to use a hostname.
Being opaque and non-human-meaningful is important for some of the places where it’s useful, because if a string is human-meaningful (like a hostname), then people will sometimes want to change it, and when they do, anything that was recording machine-specific state with the hostname as unique identifier will no longer be able to associate the machine-specific state with the machine, effectively resulting in data loss.
It is documented that every machine should have an unique machine-id, and strange things may happen when multiple machines with the same machine-id operate simultaneously.
What is it used for
List of things the machine-id is used for (please supplement the list with your knowledge)
- creation of DHCP host identifier (probably causing multiple machines fighting over the same IP address on the DHCP server)
- GNOME stores screen layout configuration keyed by machine ID
- the systemd-boot EFI bootloader stores the OS installation’s kernel(s) in a directory named after the machine ID to prevent collisions.
machine id and cloned systems, generating a new machine id
The machine id is something that is frequently missed to change when cloning a machine. A new machine-id can be generated by
Making /etc/machine-id a 0-byte file is considered to be the canonical way to clear it, rather than actually deleting it, because if systemd is running on a completely read-only root filesystem, it has code to create a machine ID on a tmpfs and bind-mount it over the top of the empty file.
If you are doing cloning, stateless systems or similar activities, and you know you will have a valid /etc/machine-id (you either use systemd or have taken other steps to have one), then you can make /var/lib/dbus/machine-id a symlink to /etc/machine-id (dbus comes with a systemd-tmpfiles file to do this). This is not done by default in Debian, or by dbus-uuidgen —ensure, for historical reasons; maybe it should be, but to be confident that it was a correct change I’d have to think about the ways in which it might go wrong on non-systemd systems (with either a non-systemd init like sysvinit, or no init at all like minimal chroots).
Missing or desyncronized machine-id files can lead to all kinds of weird behavior, for example:
- machine coming up without any networking if systemd-networkd is used
machine id and containers / chroots
systemd-nspawn already sets up a machine ID for its containers, and lxc (presumably also lxd) normally runs init, but schroot and Docker don’t normally run init and also don’t take any particular steps to have a machine ID.
Flatpak copies the machine ID from the host system into its containers, and I would assume that other frameworks with «app containers» that are conceptually part of the host machine rather than their own machine, like Snap and ?AppImage, probably do the same.
Источник
Можно ли изменить / etc / machine-id?
Я клонировал диск (SSD) и вставил клонированный диск в другую машину. Теперь обе системы имеют одинаковое значение в /etc/machine-id . Есть ли проблема просто редактировать, /etc/machine-id чтобы изменить значение? Могу ли я сделать это во время работы системы (или мне нужно загрузиться с Live USB)?
Является ли systemd-machine-id-setup лучшая альтернатива?
Наивное использование systemd-machine-id-setup не работает. Я попробовал эти шаги:
Новое значение совпадает со старым значением.
Хотя systemd-machine-id-setup и systemd-firstboot отлично /etc/machine-id подходит для систем, использующих systemd, это не системный файл, несмотря на тег. Он также используется в системах, которые не используют systemd. В качестве альтернативы вы можете использовать dbus-uuidgen инструмент:
Как упомянул Стивен Китт, системы Debian могут иметь как файл , так /etc/machine-id и /var/lib/dbus/machine-id файл. Если оба существуют как обычные файлы, их содержимое должно совпадать, поэтому там также удалите /var/lib/dbus/machine-id :
и воссоздайте его:
Эта последняя команда неявно использует в /var/lib/dbus/machine-id качестве имени файла и будет копировать идентификатор машины из уже созданного /etc/machine-id .
dbus-uuidgen Вызов может или не может уже быть частью обычной последовательности загрузки. Если это часть последовательности загрузки, то удаления файла и перезагрузки должно быть достаточно. Если вам нужно запустить dbus-uuidgen себя, обратите внимание на предупреждение в справочной странице:
Если вы попытаетесь изменить существующий идентификатор машины в работающей системе, это, вероятно, приведет к плохим вещам. Не пытайтесь изменить этот файл. Кроме того, не делайте это одинаковым в двух разных системах; он должен отличаться каждый раз, когда работают два разных ядра.
Поэтому после этого определенно не продолжайте использовать систему без перезагрузки. В качестве дополнительной меры предосторожности вы можете вместо этого сначала перезагрузиться в режиме восстановления (или, как вы предложили, загрузить с USB-флешки), но, по моему опыту, в этом нет необходимости. Может случиться что-то плохое, но все равно плохие вещи исправляются перезагрузкой.
Источник
Можно ли изменить /etc /machine-id?
Я клонировал диск (SSD) и поместил клонированный диск в другую машину. Теперь обе системы имеют одинаковое значение в /etc/machine-id . Не стоит ли просто редактировать /etc/machine-id , чтобы изменить значение? Могу ли я сделать это во время работы системы (или мне нужно загрузить с Live USB)?
Является systemd-machine-id-setup лучшая альтернатива?
Наивное использование systemd-machine-id-setup не работает. Я проделал следующие шаги:
Новое значение совпадает со старым значением.
2 ответа
Хотя systemd-machine-id-setup и systemd-firstboot являются отлично подходит для систем, использующих systemd, /etc/machine-id не является файлом systemd, несмотря на тег. Он также используется в системах, которые не используют systemd. В качестве альтернативы вы можете использовать инструмент dbus-uuidgen :
Как уже упоминалось Стивеном Киттом, системы Debian могут иметь как /etc/machine-id , так и /var/lib/dbus/machine-id . Если они существуют как обычные файлы, их содержимое должно совпадать, поэтому там также удалите /var/lib/dbus/machine-id :
и заново создайте его:
Эта последняя команда неявно использует /var/lib/dbus/machine-id в качестве имени файла и скопирует идентификатор машины из уже созданного /etc/machine-id
Вызов dbus-uuidgen может быть или не быть частью обычной последовательности загрузки. Если это часть последовательности загрузки, то удаление файла и перезагрузка должны быть достаточными. Если вам нужно запустить dbus-uuidgen самостоятельно, обратите внимание на предупреждение на странице руководства:
Если вы попытаетесь изменить существующий идентификатор машины в запущенной системе, это, вероятно, приведет к плохим вещам. Не пытайтесь изменить этот файл. Кроме того, не делайте то же самое на двух разных системах; он должен быть другим в любое время, когда работают два разных ядра.
Поэтому, после этого, определенно не продолжайте использовать систему без перезагрузки. В качестве дополнительной меры предосторожности вы можете сначала перезагрузиться в режим спасения (или, как вы сказали, загрузитесь с живого USB-накопителя), но из моего опыта это не является необходимым. Плохие вещи могут случиться, но плохие вещи, которые происходят, фиксируются перезагрузкой в любом случае.
Самый простой вариант — удалить /etc/machine-id на клонированном диске и перезагрузиться; systemd-machine-id-setup создаст новый для вас (вам нужно будет запустить его вручную, если это не произойдет автоматически). Вам также может потребоваться удалить /var/lib/dbus/machine-id (если это не символическая ссылка на /etc/machine-id ); в этом случае убедитесь, что новый machine-id действительно новый, и скопируйте файлы, чтобы /etc/machine-id и /var/lib/dbus/machine-id содержат то же значение.
Как вы узнали, запустите systemd-machine-id-setup в системе, загруженной с помощью /etc/machine-id будет просто восстановить идентификатор, с которым он был загружен (с идентификатора машины D-Bus). Это вариант 1 в man-странице, с которой вы связаны. При удалении файла (ов) и перезагрузки будет выполняться опция 4.
В интересах читателей планирование при клонировании диска таким образом рекомендуется использовать метод systemd, по крайней мере, в системах, где systemd-firstboot доступно, это используйте это вместо:
- клонировать диск;
- монтируйте клонированный корневой раздел где-нибудь (, например. /mnt );
инициализировать идентификатор машины:
Вы можете использовать systemd-firstboot , чтобы установить другие параметры, пока вы на нем (имя хоста, пароль root и т. д.).
Источник
Ubuntu Linux machine-id
Введение
Файл /etc/machine-id содержит уникальный идентификатор локальной системы — machine ID.
machine ID устанавливается во время установки или загрузки Ubuntu.
Идентификатор машины представляет собой один шестнадцатеричный идентификатор, заканчивающийся новой строкой , состоящий из 32 символов в нижнем регистре.
При декодировании из шестнадцатеричного числа это соответствует 16-байтовому/128-битному значению.
Этот идентификатор не может содержать только нули.
Идентификатор машины обычно генерируется из случайного источника во время установки системы или первой загрузки и остается постоянным для всех последующих загрузок.
Для систем без состояния (stateless), при необходимости он может быть сгенерирован во время выполнения во время ранней загрузки.
Идентификатор машины может быть задан, например, при загрузке по сети, с помощью параметра командной строки ядра
Или путем передачи параметра —machine-id= в systemd.
Идентификатор , указанный таким образом, имеет более высокий приоритет и будет использоваться вместо идентификатора, хранящегося в /etc/machine-id .
Идентификатор компьютера не изменяется в зависимости от локальной или сетевой конфигурации или когда оборудование замененный.
Из-за этого свойства, а также его большей длины он является более полезной заменой вызова gethostid(3), указанного в POSIX.
Этот идентификатор машины соответствует тому же формату и логике, что и идентификатор машины D-Bus.
Этот идентификатор однозначно идентифицирует хост. Это должно считаться «конфиденциальным» и не должно подвергаться воздействию в ненадежных средах, в частности в сети.
Если стабильная какому-то приложению необходимм уникальный идентификатор, привязанный к машине, machine ID или любая его часть не должны использоваться напрямую.
Вместо этого идентификатор машины должен быть хэширован с помощью криптографической хэш-функции с ключом, используя фиксированный ключ для конкретного приложения.
Таким образом, идентификатор будет должным образом уникальным и постоянным образом выводится из идентификатора машины, но там не будет возможности получить исходный идентификатор компьютера из конкретного приложения.
API sd_id128_get_machine_app_specific(3) предоставляет реализацию такого алгоритма.
Источник