On Sun, 18 Aug 2019 at 13:57:58 +0200, Marc Haber wrote:
> On Tue, 13 Aug 2019 18:30:51 +0100, Simon McVittie
> >bubblewrap and other container-runners often use this when setting
> >up containers - for example if you have a Flatpak app installed, try
> >something like
> >
> >flatpak run --com
On Tue, 13 Aug 2019 18:30:51 +0100, Simon McVittie
wrote:
>On Tue, 13 Aug 2019 at 14:22:31 +0200, Marc Haber wrote:
>> On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie
>> wrote:
>> >(systemd cannot create a mount point that doesn't exist yet on a read-only
>> >file system, which is why a zero-b
>Longer answer: it’s complicated, but I’m sure there’s
>a set of bind and non-bind mounts that will work for
>systemd as well.
>
>Back to topic now. Or I’m going pet the cat.
Well, it *is* on topic. I have been using the same strategy for sysvinit and
systemd systems for many years with great suc
Dominik George dixit:
>>than you think, either bind-mount tons of filesystem from the host,
>>and this is only safe-ish if both run sysvinit
>Why should that not work on systemd?
I wrote safe-ish and deliberately didn’t focus on this
as it’s not relevant for the point I was trying to make.
Long
>than you think, either bind-mount tons of filesystem from the host,
>and this is only safe-ish if both run sysvinit
Like most of the time, your allegation is lacking any facts and sources.
Why should that not work on systemd?
-nik
>At a glance, there are also unique LVM IDs in /boot/grub/grub.cfg,
>though whether those would need to be changed when cloning I don't know.
Normally, you mount the root filesystem, chroot into it (more complex
than you think, either bind-mount tons of filesystem from the host,
and this is only s
On Thu, 15 Aug 2019 at 09:54:44 +0100, Ian Jackson wrote:
> Do we have a list of all the things this is (or might be) used for ?
As I said, I don't think a comprehensive list is feasible without
resorting to something like codesearch, because it's of similar scope to
a list of reasons to use the h
Simon McVittie writes ("Re: Generating new IDs for cloning (was Re: duplicate
popularity-contest ID)"):
> Somehow describing which containers and chroots should have a machine ID,
> which ones should share the host's machine ID and which ones don't need
> either is
On Tue, 13 Aug 2019 at 22:01:34 -0400, Theodore Y. Ts'o wrote:
> That's just a matter of having sysvinit (and other non-systemd init
> systems) have an init script which runs as soon as the root file
> system is remounted read/write to initialize /etc/machine-id if it
> doesn't exist or if it is a
On Tue, Aug 13, 2019 at 06:30:51PM +0100, Simon McVittie wrote:
> > >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in
> > >> >general (systemd or not)?
> >
> > So /etc/machine-id should be in Policy?
>
> Probably yes, if that proposal has consensus, although a prerequisi
On Tue, 13 Aug 2019 at 14:22:31 +0200, Marc Haber wrote:
> On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie
> wrote:
> >(systemd cannot create a mount point that doesn't exist yet on a read-only
> >file system, which is why a zero-byte file is preferred.
>
> but you can bind-mount over a file?
On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie
wrote:
>(systemd cannot create a mount point that doesn't exist yet on a read-only
>file system, which is why a zero-byte file is preferred.
but you can bind-mount over a file? I wasn't aware of that.
>If you use systemd as init, install dbus, d
> "Simon" == Simon McVittie writes:
Simon> If you use systemd as init, install dbus, delete or empty
Simon> /etc/machine-id, delete /var/lib/dbus/machine-id and reboot,
It is my experience that deleting /etc/machine-id doesn't actually work
(even if I delete the dbus machine id too).
On Tue, 13 Aug 2019 at 11:50:27 +0200, Marc Haber wrote:
> On Thu, 8 Aug 2019 22:44:19 +0100, Simon McVittie
> wrote:
> >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 rea
On Thu, 8 Aug 2019 22:44:19 +0100, Simon McVittie
wrote:
>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 tm
On Thu, 8 Aug 2019 22:59:05 +0100, Simon McVittie
wrote:
>On Thu, 08 Aug 2019 at 08:37:16 -0400, Marvin Renich wrote:
>> Does anyone know what applications use this file for what purpose? Is
>> this a systemd-ism?
>
>It originated as /var/lib/dbus/machine-id in D-Bus, and systemd picked it
>up an
On Thu, 08 Aug 2019 at 08:37:16 -0400, Marvin Renich wrote:
> Does anyone know what applications use this file for what purpose? Is
> this a systemd-ism?
It originated as /var/lib/dbus/machine-id in D-Bus, and systemd picked it
up and generalized it into something non-D-Bus-specific. It isn't rea
On Thu, 08 Aug 2019 at 13:39:54 +0200, Marc Haber wrote:
> Generating a new machine-id doesn't seem as easy as generating a new
> ssh key: Removing /etc/machine-id doesn't do it as
> systemd-machine-id-setup seems to pull the machine-id from dbus.
For historical reasons (dbus originated the concep
* Michael Stone [190808 12:34]:
> I guess I need you to say what's confusing. It's an ID that doesn't change.
> You can look up gethostid to get a little more background. If you need an ID
First, let me say that I am not trying to be intentionally obtuse. I am
really interested to know what prog
Michael Stone writes:
> So to find out what applications use the file you'd have to look for
> references to the various APIs (such as
> sd_id128_get_machine_app_specific or dbus-uuidgen) which themselves use
> /etc/machine-id
I believe the point of the question was to see if anyone had already
On Wed, 7 Aug 2019 11:15:22 -0400, Marvin Renich
wrote:
>I think this is a good idea, but will require work and coordination to
>accomplish. A wiki.debian.org page with your ideas and (perhaps on a
>separate page) a place to list things that need updating after the
>physical copying is complete w
On Thu, Aug 08, 2019 at 06:16:31PM +0200, Marc Haber wrote:
On Thu, 8 Aug 2019 11:50:07 -0400, Michael Stone
wrote:
On Thu, Aug 08, 2019 at 11:41:52AM -0400, Marvin Renich wrote:
* Michael Stone [190808 08:42]:
On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
> Does anyone know
On Thu, 8 Aug 2019 11:50:07 -0400, Michael Stone
wrote:
>On Thu, Aug 08, 2019 at 11:41:52AM -0400, Marvin Renich wrote:
>>* Michael Stone [190808 08:42]:
>>> On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
>>> > Does anyone know what applications use this file for what purpose? Is
On Thu, Aug 08, 2019 at 11:41:52AM -0400, Marvin Renich wrote:
* Michael Stone [190808 08:42]:
On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
> Does anyone know what applications use this file for what purpose? Is
> this a systemd-ism?
man machine-id
The man page says what i
* Michael Stone [190808 08:42]:
> On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
> > Does anyone know what applications use this file for what purpose? Is
> > this a systemd-ism?
>
> man machine-id
The man page says what it is (a unique, random ID for the machine) and
how to ini
On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
Does anyone know what applications use this file for what purpose? Is
this a systemd-ism?
man machine-id
* Bernhard Schmidt [190808 07:48]:
> Am 08.08.19 um 13:39 schrieb Marc Haber:
> > How do I generate a new one?
>
> I followed
> https://unix.stackexchange.com/questions/402999/it-is-ok-to-change-etc-machine-id
> last time which means
Hmm. The advice in that link doesn't match what man machine-i
Am 08.08.19 um 13:39 schrieb Marc Haber:
> On Wed, 07 Aug 2019 09:28:12 -0400, The Wanderer
> wrote:
>> On 2019-08-07 at 04:26, Russell Stuart wrote:
>>
>>> On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote:
>>>
I am using Debian for two decades now, and I realized that
necessity two d
On Wed, 07 Aug 2019 09:28:12 -0400, The Wanderer
wrote:
>On 2019-08-07 at 04:26, Russell Stuart wrote:
>
>> On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote:
>>
>>> I am using Debian for two decades now, and I realized that
>>> necessity two days ago.
>>
>> Ditto - except for me it was a few
On 2019-08-07 at 16:59, Andrei POPESCU wrote:
> On Mi, 07 aug 19, 09:28:12, The Wanderer wrote:
>
>> I've begun to wonder whether it might be worth the overhead to set up
>> some type of mechanism to let packages which define such
>> machine-specific IDs A: declare the fact, in a central location
On Thu, Aug 8, 2019 at 4:59 AM Andrei POPESCU wrote:
> 1. Delete the contents of /etc (all of it)
> 2. If a package doesn't find its "stuff" in /etc it regenerates it from
> defaults.
There is still way too much stuff that defaults to installing
important files in /etc (default config settings, i
On Mi, 07 aug 19, 09:28:12, The Wanderer wrote:
>
> I've begun to wonder whether it might be worth the overhead to set up
> some type of mechanism to let packages which define such
> machine-specific IDs A: declare the fact, in a central location which
Do you mean /etc? :)
> the sysadmin of a ma
The Wanderer writes:
> This isn't the first time I've discovered that some aspect of a Debian
> system would actually need to be cleared and re-generated when that
> system is cloned, well after the point where it would have been easy for
> me to address that need. (Fortunately, although I've mov
* The Wanderer [190807 09:28]:
> Cloning isn't the only example of a case where some machine-specific
> configuration detail may need to be updated, without that being obvious
> in advance.
>
> I've begun to wonder whether it might be worth the overhead to set up
> some type of mechanism to let p
On 2019-08-07 at 04:26, Russell Stuart wrote:
> On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote:
>
>> I am using Debian for two decades now, and I realized that
>> necessity two days ago.
>
> Ditto - except for me it was a few seconds ago.
In my case, it was when I read this thread last nig
35 matches
Mail list logo
