Re: [DNG] Request for testing of slim/experimental

[aitor_czr]

Hi,

On 7/3/19 14:31, KatolaZ wrote:

On Thu, Mar 07, 2019 at 08:13:01AM -0500, Hendrik Boom wrote:

Is beowulf already in a state where it is generally useable for an ordinary
user on a laptop?  Except maybe a few quirks like the one we're now
debugging?  If so I'll upgrade soon and look for problems.  I'd prefer not
to have to downgrade or reinstall if my system becomes unusable.


Define "ordinary user on a laptop". I have been using beowulf since
about 8 months ago on my laptop, and haven't experience any major
breakage (but I should probably also definne "major breakage"
here). My impression is that beowulf is pretty usable, but I am not
running a DE so my experience does not cover session-related automagic
goodies.

It would be great if more people would actually move on beowulf as
soon as possible, so that we can identify as many glitches as possible
and put together a beta of beowulf.

HND

KatolaZ
My latest image of gnuinos beowulf (not uploaded yet) waits for a 
keyboard press event during live boots.
I'm still not sure if this is related with the new version of slim. I'll 
check it soon. Another possible cause might be
the non configured live-config scripts. Daniel Baumann would throw up 
his arms, but i always use a very simple script for that

because it just worked for me during years.

Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /var/lib/dbus/machine-id -- new dbus version

[Alessandro Selli]

On 08/03/19 at 23:58, KatolaZ wrote:
> Dear D1rs,
>
> following the discussion about /var/lib/dbus/machine-id, you find a
> new version of dbus in unstable and beowulf. The new version is
> 1.12.12-1+devuan2, and it should hit pkgmaster in the next 10 minutes.
>
> I have added a variable "IDTYPE" in /etc/default/dbus which is set by
> default to "RANDOM". This will result in /var/lib/dbus/machine-id
> being re-generated at boot time (and only at boot time). If IDTYPE is
> set to anything else, /var/lib/dbus/machine-id is preserved across
> subsequent boots. In this way, the sysadmin can choose to have the
> dbus machine-id persist across boots, if they like, but the default
> beaviour will be to have it re-generated at each boot.
>
> Please test it out and report any issue. There is an open bug (#304)
> on bugs.devuan.org. Use that one for comments/updates please.


  Goor.  My /var/lib/dbus/machine-id dates Sept., I'll report shall it
not change next reboot.


> Regarding /etc/machine-id: it looks like it is installed only by
> systemd, so any devuan installation which originally was a Debian
> might probably have it. My guess is that it should be possible to
> remove it altogether. If any application wants it (somebody mentioned
> chromium) you could replace it with a symlink to
> /var/lib/dbus/machine-id.
>
> I guess replacing /etc/machine-id every 10 minutes to avoid chromium
> tracking you is not particularly smart: I am pretty sure chromium
> would just read it when it starts, and then keep it in RAM, so you
> might need to restart chromium every 10 minutes as well.


  Plus, I would not make it evident to programs that my machine-id value
is bogus.  I'd let them believe it's a good one across the session.


  Bye,



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[aitor_czr]

Hi,

On 8/3/19 18:31, . fsmithred via Dng wrote:

There's no /etc/machine-id in my beowulf that was an upgrade from
refracta ascii or in the beowulf live iso that I just made with
live-sdk.

Refractasnapshot excludes /var/lib/dbus/machine-id and blanks
/etc/machine-id if it's present.

Refractainstaller excludes /var/lib/dbus/machine-id and does nothing
with /etc/machine-id.

Isos made with live-sdk will have /var/lib/dbus/machine-id, and it's
the same number every boot unless we remove the file. I just added 'rm
-f /var/lib/dbus/machine-id' to blend_finalize() and now the iso has a
different machine-id on every boot.

If /etc/machine-id is missing, systemd-journald will fail. If the file
is empty, it'll get a new number. (That doesn't concern us, but
there's code for it in refractasnapshot because people use that on
debian with systemd.)

fsmithred
I'm looking at the generated strapdir in my live-sdk (built on thursday) 
and i've got the same result:
/etc/machine-d is missing and the other file /var/lib/dbus/machine-d is 
present.


Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Alessandro Selli]

On 09/03/19 at 00:28, Arnt Karlsen wrote:
> On Fri, 8 Mar 2019 22:56:36 +0100, Alessandro wrote in message 
> <93850f1a-3feb-adc9-1cd0-8ca8736fc...@linux.com>:
>
>> On 08/03/19 at 18:38, Arnt Karlsen wrote:
>>> ..my /etc/cron.d/machine-id:
>>> PATH=/bin:/usr/bin:/sbin:/usr/sbin
>>>
>>> # ..a new /etc/machine-id every minute... ;o)
>>> * * * * * root  date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee  
>>>   >/dev/null 2>&1  
>>
>>   What is tee doing there?
> ..allows logging the generated IDs with e.g. 
> " |tee >>/var/log/machine-IDs ", some people 
> might need to do that.


  I see.  I would leave logging to it's specific command, though:


echo $RANDOM | md5sum | cut -c 1-32 > /etc/machine-id && logger -p local1.info 
'/etc/machine randomly regenerated' || logger -p local1.err 'Random 
regeneration of /etc/machine failed'

  But this is just a matter of personal choice.
 

> ..both valid improvements, me, I might go: " * * * * * root \ 
> fortune & |md5sum |cut -d" " -f-1 >/etc/machine-id |tee \
>  >/dev/null 2>&1  " to keep this lightweight in my end and not 
> in the other end. :o)


  The use of fortune as a RNG is telling of the number of gray hair you
must have!  



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /var/lib/dbus/machine-id -- new dbus version

[Arnt Karlsen]

On Fri, 8 Mar 2019 23:58:02 +0100, KatolaZ wrote in message 
<20190308225802.yzcbcl5e7rfl6...@katolaz.homeunix.net>:

> Dear D1rs,
> 
> following the discussion about /var/lib/dbus/machine-id, you find a
> new version of dbus in unstable and beowulf. The new version is
> 1.12.12-1+devuan2, and it should hit pkgmaster in the next 10 minutes.
> 
> I have added a variable "IDTYPE" in /etc/default/dbus which is set by
> default to "RANDOM". This will result in /var/lib/dbus/machine-id
> being re-generated at boot time (and only at boot time). If IDTYPE is
> set to anything else, /var/lib/dbus/machine-id is preserved across
> subsequent boots. In this way, the sysadmin can choose to have the
> dbus machine-id persist across boots, if they like, but the default
> beaviour will be to have it re-generated at each boot.
> 
> Please test it out and report any issue. There is an open bug (#304)
> on bugs.devuan.org. Use that one for comments/updates please.
> 
> Regarding /etc/machine-id: it looks like it is installed only by
> systemd, so any devuan installation which originally was a Debian
> might probably have it. My guess is that it should be possible to
> remove it altogether. If any application wants it (somebody mentioned
> chromium) you could replace it with a symlink to
> /var/lib/dbus/machine-id.

..I disagree with this symlink idea.  
I have seen no bad effect having
these 2 ID-files differ.

> 
> I guess replacing /etc/machine-id every 10 minutes to avoid chromium
> tracking you is not particularly smart: I am pretty sure chromium
> would just read it when it starts, and then keep it in RAM, so you
> might need to restart chromium every 10 minutes as well.

..the bigger problem with chromium et al is we don't really know 
much about how they track us, which is why these ID tracker web
browsers should only be run once, in throw-away virtual machines.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Arnt Karlsen]

On Fri, 8 Mar 2019 22:56:36 +0100, Alessandro wrote in message 
<93850f1a-3feb-adc9-1cd0-8ca8736fc...@linux.com>:

> On 08/03/19 at 18:38, Arnt Karlsen wrote:
> >
> > ..my /etc/cron.d/machine-id:
> > PATH=/bin:/usr/bin:/sbin:/usr/sbin
> >
> > # ..a new /etc/machine-id every minute... ;o)
> > * * * * * root  date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee  
> >   >/dev/null 2>&1  
> 
> 
>   What is tee doing there?

..allows logging the generated IDs with e.g. 
" |tee >>/var/log/machine-IDs ", some people 
might need to do that. 

>   It duplicates it's standard input to each of the files it sees as
> parameters, and it has none.
> 
>   Plus, it emits it's standard input to it's standard output, which
> gets discarded.
> 
>   What is the purpose of doing this?
> 
> 
>   I'd just do this instead:
> 
> echo $RANDOM | md5sum | cut -c 1-32 > /etc/machine-id
> 
> 
> or maybe:
> 
> 
> dd count=1 if=/dev/urandom 2> /dev/null | md5sum | cut -c 1-32 >
> /etc/machine-id

..both valid improvements, me, I might go: " * * * * * root \ 
fortune & |md5sum |cut -d" " -f-1 >/etc/machine-id |tee \
 >/dev/null 2>&1  " to keep this lightweight in my end and not 
in the other end. :o)


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] /var/lib/dbus/machine-id -- new dbus version

[KatolaZ]

Dear D1rs,

following the discussion about /var/lib/dbus/machine-id, you find a
new version of dbus in unstable and beowulf. The new version is
1.12.12-1+devuan2, and it should hit pkgmaster in the next 10 minutes.

I have added a variable "IDTYPE" in /etc/default/dbus which is set by
default to "RANDOM". This will result in /var/lib/dbus/machine-id
being re-generated at boot time (and only at boot time). If IDTYPE is
set to anything else, /var/lib/dbus/machine-id is preserved across
subsequent boots. In this way, the sysadmin can choose to have the
dbus machine-id persist across boots, if they like, but the default
beaviour will be to have it re-generated at each boot.

Please test it out and report any issue. There is an open bug (#304)
on bugs.devuan.org. Use that one for comments/updates please.

Regarding /etc/machine-id: it looks like it is installed only by
systemd, so any devuan installation which originally was a Debian
might probably have it. My guess is that it should be possible to
remove it altogether. If any application wants it (somebody mentioned
chromium) you could replace it with a symlink to
/var/lib/dbus/machine-id.

I guess replacing /etc/machine-id every 10 minutes to avoid chromium
tracking you is not particularly smart: I am pretty sure chromium
would just read it when it starts, and then keep it in RAM, so you
might need to restart chromium every 10 minutes as well.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Alessandro Selli]

On 08/03/19 at 18:38, Arnt Karlsen wrote:
>
> ..my /etc/cron.d/machine-id:
> PATH=/bin:/usr/bin:/sbin:/usr/sbin
>
> # ..a new /etc/machine-id every minute... ;o)
> * * * * * root  date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee
>   >/dev/null 2>&1


  What is tee doing there?

  It duplicates it's standard input to each of the files it sees as
parameters, and it has none.

  Plus, it emits it's standard input to it's standard output, which gets
discarded.

  What is the purpose of doing this?


  I'd just do this instead:

echo $RANDOM | md5sum | cut -c 1-32 > /etc/machine-id


or maybe:


dd count=1 if=/dev/urandom 2> /dev/null | md5sum | cut -c 1-32 >
/etc/machine-id


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] simple-netaid-backend debugged.

[Alessandro Selli]

On 08/03/19 at 01:34, Rick Moen wrote:
> 'netstat -nalp' is hard-wired into my memory, whereas I have to look up
> the 'ss' equivalent, every time.


  You're lucky, as the ss equivalent of netstat -nalp is ss -nalp!


-n, --numeric Do not try to resolve service names.

-a, --all Display both listening and non-listening

-l, --listening Display only listening sockets (useless together with -a)

-p, --processes Show process using socket.


  Just like the same options for the netstat command.


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] simple-netaid-backend debugged.

[Alessandro Selli]

On 08/03/19 at 16:30, Bot Fap wrote:
>
>
> On Fri, 8 Mar 2019, 00:10 Alessandro Selli,  > wrote:
>
> On 08/03/19 at 00:50, Ralph Ronnquist via Dng wrote:
> >
> > It's intriguing to see you get so emotional about this.
>
>
>   My objections are technically motivated and documented.
>
>   Yours are neither
>
>
> You should re-read your posts. You come across as very emotional and
> with a superiority complex about another user using a tool that you
> choose not to use.


  I stated facts:

1) ifconfig and iwconfig are considered obsolete, deprecated and pending
removal by all major distributions, to the point some removed them 5
years ago and many no longer install them by default.

2) They were substituted by the commands ip and iw, that have been long
made not just available, but installed as the reference network
configuration tools by all major ditributions.

3) the old commands suffer from many limitations and are no longer been
extended to incorporate the latest (and even not so "latest") networking
features the kernel supports.


These are facts, not opinions or emotions.


>
> You then wrongly tell the other user that tool is deprecated when it
> very much is not, certainty in the embedded world, if not so much the
> desktop


  They are, and I provided with links to demonstrate it.  No one of
those who state the opposite managed to show anything to support their
claims to the opposite.


>
>
> > Just the other week I opted for using ifconfig because I
> couldn't work
> > out the single command for confguring a tap with an IP address, and
> > bring it up. With ip, I seemed to need 3 commands, so at that time I
> > liked ifconfig better.
>
>
>   Your own failures at using modern tools and your personal
> preferences
> are not technically compelling reasons to consider outdated and
> deprecated commands anything different than what they are.
>
>
> Choosing to use a different tool because of familiarity is not a
> failure it's a choice.


  Chosing to use a deprecated and obolete tool that lacks many feature
that have been supported by the kernel for 15+ years for no other reason
than "I'm used at using them" is stupid.


> There you go again being abusive to people for making different
> choices than you


  I have nothing to say against other people's choice.  I have a lot to
say about technical reasons those commanda are deprecated and obsolete
and no longer worked on to make them current.


>
>
> > It's certainly not obsolete yet.
>
>
>   They surely are, and Rick and myself provided with links to document
> this and a list of shortcomings that plague those commands.  You
> failed
> at documenting anything technical to prop up your personal
> convictions.
>
>
> If over 1 billion deployments in the last 12 months is obsolete then
> you clearly have a very different definition of obsolete to the rest
> of the world. Again you are being abusive to try and force your point
> of view (not facts)


  facts are that not one of the major distributions depends on those
commands.  They are no longer required, they are still available just
for the fun of the dinosaurs who insist in using deprecated and obsolete
tools for no technical advantage.


>
>
> >  Perhaps there is
> > a single ip command, and perhaps I can learn it, but that still
> wouldn't
> > make ifconfig obsolete.
>
>   Again, your failure/unwillingness at learning modern tools does not
> make them bad and does not make deprecated and obsolete commands
> modern
> and up to date.
>
>
> > Though, I realise I should let you call it/them "deprecated";
>
>
>   It's not just me, it's many thousand people who do.
>
> Any many thousands more completely disagree with you. Stop confusing
> your opinions with facts


  Please provide with pointers to technical papers documenting that
ifconfig and iwconfig can do everything that ip and iw do.

Otherwise just shut up.


>
>
> >  it may
> > well be how you think of them even if I don't do that.
>
>
>   It's not just that I think they are.  They are considered to be that
> way by an overwhelming majority of Linux developers and sysadmins.
>
> Not true in the slightest. Devs maybe, sysadmins absolutely not


  Sysadmins do, too.  Because they cannot do many things that their job
requires them to do with the old tools.


>
>
> > The word is just
> > an expression of an opinion about these programs and not an
> attribute of
> > them.
> >
> > Ralph.
>
>
>   Still nothing technical about how those commands could be considered
> anything different than obsolete and deprecated.  You only have your
> personal convictions to show.
>
>
> Which is exactly the same as you have.


  Again, I provided with pointers to back up my claims.  Not one of
those who insist I am wrong could.


-- 
Alessandro Selli 
VOIP SIP: 

Re: [DNG] simple-netaid-backend debugged.

[Alessandro Selli]

On 08/03/19 at 05:26, terryc wrote:
> On Thu, 7 Mar 2019 22:05:39 +0100
> Alessandro Selli  wrote:
>
>> On 07/03/19 at 21:22, Ralph Ronnquist via Dng wrote:
>>> Alessandro Selli wrote on 8/3/19 6:49 am:  
   Next improvement would be using current commands (ip and iw) in
 place of the obsolete and deprecated ones, i.e. ifconfig and
 iwconfig:  
>>> The terms "obsolete" and "deprecated" are badly chosen, since the
>>> programs ifconfig and iwconfig are neither.  
>>
>>   Yes, they are.  They are pending removal from several (all?) major
>> distributions, some already removed them years ago,
> Should I not mention systemd.


  It's off-topic in tis context.  At least for now.


> I'm sure it is a drop in replacement in
> that sentence above.


  Right now ip and iw are.


>> You are of course free to ignore facts.  We do live in a free society.
> Shrug, no such thing as facts. Just common majority accepted
> explanations for "reality'.


  And of course you are one of the very few chosen ones who could grasp
the only real truth, right?



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Ralph Ronnquist via Dng]

KatolaZ wrote on 9/3/19 1:00 am:
> On Fri, Mar 08, 2019 at 01:49:20PM +, Mark Hindley wrote:
>> On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote:
>>> Jaromil,
>>>
>>> this is currently managed by eudev in devuan and, IIRC, it is simply
>>> regenerated as a random ID at each boot.

Apparently, on my beowulf VM, the file /var/lib/dbus/machine-id is
created when 'dbus' is installed (r reinstalled), and it's not changed
or regenerated at reboot. /etc/machine-id is not present.

Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Arnt Karlsen]

On Fri, 8 Mar 2019 19:18:10 +0100, KatolaZ wrote in message 
<20190308181810.7wnfugnqmqtie...@katolaz.homeunix.net>:

> anyway:
> 
> - /etc/hostid is defined in POSIX 2001 and POSIX 2008 (man gethostid)
> 
> - /proc/sys/kernel/random/boot_id is randomly generated by the kernel
>   at each boot (see drivers/char/random.c and kernel/sysctl.c in the
>   kernel tree)
>   
> - /var/lib/dbus/machine-id is used by dbus, and at the moment seems to
>   not being re-generated at each boot (my recollection was wrong: we
>   will fix it)

..do we need /var/lib/dbus/machine-id et al ID files at all?

..if we need them, can we recreate the(se) ID file(s) by e.g.
restarting dbus e.g. every minute?


..should we allow e.g. web browsers to read these ID files?

..if we allow e.g. web browsers to read these ID files, do we 
offer One Devuan ID for Mankind, or do we drown them in an 
avalance of random machine IDs?

> - /etc/machine-id should be used only by systemd components.

..totally agree, but e.g. chromium (ab)uses it:
"[20478:20478:0307/101807.205617:ERROR:browser_dm_token_storage_linux.cc(101)]
Error: /etc/machine-id contains 0 characters (32 were expected)"

..given their history, I wouldn't be surprised to learn they use 
any of the other ID files.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Rick Moen]

Quoting Arnt Karlsen (a...@iaksess.no):

> ..my /etc/cron.d/machine-id:
> PATH=/bin:/usr/bin:/sbin:/usr/sbin
> 
> # ..a new /etc/machine-id every minute... ;o)
> * * * * * root  date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee
>   >/dev/null 2>&1

_Very_ nice solution.  I think I'll steal it whenever I finally need
/etc/machine-id .

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Request for testing of slim/experimental

[Mark Hindley]

On Thu, Mar 07, 2019 at 08:31:33AM +1100, Ralph Ronnquist via Dng wrote:
> So, apparently 'slim' since long ago believes something else is
> responsible for registring the session(s), but that something else
> doesn't agree.

Would people who are experiencing missing slim utmp entries mind trying again
with the following configuration added to /etc/slim.conf, please?

sessionstop_cmd exec /usr/bin/sessreg -d -l $DISPLAY %user
sessionstart_cmd exec /usr/bin/sessreg -a -l $DISPLAY %user

If you don't have the sessreg command it is in the package x11-xserver-utils.

Thanks

Mark
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Stefan Krusche]

Am Freitag, 8. März 2019 schrieb KatolaZ:
> On the other hand, it looks like /etc/machine-id mighr come from
> Debian installations "converted" to Devuan, but we should check
> whether any of the installer components might have put it there. We
> should collect as many reports as possible of things that won't work
> if /etc/machine-id does not exist.
>
> Anybody willing to help with this: if your Devuan installation has a
> file /etc/machine-id, could you please move/remove it and report any
> application complaining about that, including the version of Devuan
> you are using?

On my Devuan/ascii machine which I installed May/June 2018 it looks like 
this:

$ ll /var/lib/dbus/machine-id
-rw-r--r-- 1 root root 33 2018.05.31 23:45.19 /var/lib/dbus/machine-id
$ ll /etc/machine-id
ls: cannot access '/etc/machine-id': No such file or directory

That was a new install and /etc/machine-id apparently wasn't created, 
while /var/lib/dbus/machine-id was created at installation time and 
stayed there like that.

I believe but am not 100% sure that I used 
devuan_ascii_2.0.0-rc_amd64_netinst.iso from May 2018, at least this 
file has a time stamp from that time.

HTH

Kind regards,
Stefan

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[golinux]

On 2019-03-08 11:50, KatolaZ wrote:

On Fri, Mar 08, 2019 at 12:31:55PM -0500, . fsmithred via Dng wrote:

On 3/8/19, KatolaZ  wrote:
>
> Then we could probably just ignore it, right? It turns out I was
> making confusion between /etc/machine-id and
> /car/lib/dbus/machine-id. There is no /etc/machine-id in any of my
> machines, either on ascii or on beowulf, and I had forgotten you had
> pushed the patch to elogind to use the dbus machine-id instead.
>
> We should just double-check that the dbus machine-id is regenerated at
> reboot, as expected.
>

There's no /etc/machine-id in my beowulf that was an upgrade from
refracta ascii or in the beowulf live iso that I just made with
live-sdk.

Refractasnapshot excludes /var/lib/dbus/machine-id and blanks
/etc/machine-id if it's present.

Refractainstaller excludes /var/lib/dbus/machine-id and does nothing
with /etc/machine-id.

Isos made with live-sdk will have /var/lib/dbus/machine-id, and it's
the same number every boot unless we remove the file. I just added 'rm
-f /var/lib/dbus/machine-id' to blend_finalize() and now the iso has a
different machine-id on every boot.

If /etc/machine-id is missing, systemd-journald will fail. If the file
is empty, it'll get a new number. (That doesn't concern us, but
there's code for it in refractasnapshot because people use that on
debian with systemd.)



Thanks a lot for the analysis fsmithred. I guess we should open a bug
report against dbus to correct the behaviour of the dbus init script
(and ensure that /var/lib/dbus/machine-id is regenerated at each
boot).

On the other hand, it looks like /etc/machine-id mighr come from
Debian installations "converted" to Devuan, but we should check
whether any of the installer components might have put it there. We
should collect as many reports as possible of things that won't work
if /etc/machine-id does not exist.

Anybody willing to help with this: if your Devuan installation has a
file /etc/machine-id, could you please move/remove it and report any
application complaining about that, including the version of Devuan
you are using?

Thanks

KatolaZ



This thread inspired me to finally upgrade my beowulf in VB.  
/etc/machine-id is not present after the upgrade.  Neither is it present 
in jessie or ascii in VB. All were clean installs and not migrated from 
Debian.


golinux





___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[karl]

Rowland:
> On Fri, 8 Mar 2019 11:44:49 -0600
> "Jamey Fletcher"  wrote:
...
> > I have it here on my Gentoo install - and /var/lib/dbus/machine-id is
> > a symlink to it.  It's basically the same length as a MD5SUM - why
> > not just standardize on the MD5SUM of an empty 0-byte file (
> > d41d8cd98f00b204e9800998ecf8427e ) and tell them to take a running
> > leap from the ISS?
> 
> Now that's an idea, if they are tracking us, one ID will appear to be
> everywhere at once, that should confuse them ;-)

No, it tells "them" that you are using e.g. Devuan, and that you are 
concerned about it for some reason.
Depending about how many who is doing so, you might be singled out.

If it is for tracking, best is to not to have the infrastructure for 
this at all, i.e. bug programs that wants it and tell distributions to 
stop using it.

Regards,
/Karl Hammar


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[KatolaZ]

On Fri, Mar 08, 2019 at 06:38:32PM +0100, Arnt Karlsen wrote:

[cut]

> 
> > > I don't seem to have it and everything works without it.  
> > 
> > It's on my beowulf installations, and I didn't even know that it was
> > there :-/
> 
> ..quick starting point:
> ll /proc/sys/kernel/random/boot_id /etc/hostid /etc/machine-id \
> /var/lib/dbus/machine-id /var/db/dbus/machine-id
>

$ ll
bash: ll: command not found
$

:P

anyway:

- /etc/hostid is defined in POSIX 2001 and POSIX 2008 (man gethostid)

- /proc/sys/kernel/random/boot_id is randomly generated by the kernel
  at each boot (see drivers/char/random.c and kernel/sysctl.c in the
  kernel tree)
  
- /var/lib/dbus/machine-id is used by dbus, and at the moment seems to
  not being re-generated at each boot (my recollection was wrong: we
  will fix it)

- /etc/machine-id should be used only by systemd components.

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Jamey Fletcher]

Rowland wrote:

> On Fri, 8 Mar 2019 11:44:49 -0600
> "Jamey Fletcher"  wrote:

>> I have it here on my Gentoo install - and /var/lib/dbus/machine-id is
>> a symlink to it.  It's basically the same length as a MD5SUM - why
>> not just standardize on the MD5SUM of an empty 0-byte file (
>> d41d8cd98f00b204e9800998ecf8427e ) and tell them to take a running
>> leap from the ISS?

> Now that's an idea, if they are tracking us, one ID will appear to be
> everywhere at once, that should confuse them ;-)

I had, at one point, proposed to a friend that we set up a tool that
would, any time a tracking cookie was set by DoubleClick or one of the
other tracking companies, upload it to a pool, from which anytime
DoubleClick requested said cookie from your machine, it would retrieve one
at random and return it, poisoning their database.  Probably have to do it
with a local proxy server, but seems feasible.  (Kinda like the
winnow-and-chaff satellite internet service I wanted to propose.  You send
your data, encrypted, up to the service, and it's all uploaded to the
satellite, and broadcast everywhere, along with all of the other data
being sent, mixed up randomly.  If the other end could decode it, it was
for them, everything else was just semi-random noise to make it more
difficult for the Nosy Spy Agency to classify and decrypt.  Of course,
from a few years on, I don't think it would be quite that easy, but ...
maybe, with public-key encryption?)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Rowland Penny via Dng]

On Fri, 8 Mar 2019 11:44:49 -0600
"Jamey Fletcher"  wrote:

> > Anno domini 2019 Fri, 8 Mar 10:45:04 -0600
> 
> >  Nate Bargmann scripsit:
> 
> >> * On 2019 08 Mar 08:00 -0600, KatolaZ wrote:
> 
> >>> and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
> >>> time. But we need to double-check.
> 
> >> Not on this Debian Buster machine.  Both /var/lib/dbus/machine-id
> >> and /etc/machine-id have a date/time consistent with the initial
> >> system installation back in October.  The machine has been
> >> rebooted a number of times since.  I've not tried moving either
> >> and seeing what happens on the next system restart.
> 
> > Hm ... same here:
> 
> > nik@t61:~$ ll /var/lib/dbus/machine-id
> > -rw-r--r-- 1 root root 33 Sep 15  2015 /var/lib/dbus/machine-id
> > nik@t61:~$ ll /etc/machine-id
> > -r--r--r-- 1 root root 33 Sep 15  2015 /etc/machine-id
> > nik@t61:~$
> 
> > 2015 ... that was jessie, when this computer was set up ...
> 
> I have it here on my Gentoo install - and /var/lib/dbus/machine-id is
> a symlink to it.  It's basically the same length as a MD5SUM - why
> not just standardize on the MD5SUM of an empty 0-byte file (
> d41d8cd98f00b204e9800998ecf8427e ) and tell them to take a running
> leap from the ISS?

Now that's an idea, if they are tracking us, one ID will appear to be
everywhere at once, that should confuse them ;-)

Rowland


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[KatolaZ]

On Fri, Mar 08, 2019 at 12:31:55PM -0500, . fsmithred via Dng wrote:
> On 3/8/19, KatolaZ  wrote:
> >
> > Then we could probably just ignore it, right? It turns out I was
> > making confusion between /etc/machine-id and
> > /car/lib/dbus/machine-id. There is no /etc/machine-id in any of my
> > machines, either on ascii or on beowulf, and I had forgotten you had
> > pushed the patch to elogind to use the dbus machine-id instead.
> >
> > We should just double-check that the dbus machine-id is regenerated at
> > reboot, as expected.
> >
> 
> There's no /etc/machine-id in my beowulf that was an upgrade from
> refracta ascii or in the beowulf live iso that I just made with
> live-sdk.
> 
> Refractasnapshot excludes /var/lib/dbus/machine-id and blanks
> /etc/machine-id if it's present.
> 
> Refractainstaller excludes /var/lib/dbus/machine-id and does nothing
> with /etc/machine-id.
> 
> Isos made with live-sdk will have /var/lib/dbus/machine-id, and it's
> the same number every boot unless we remove the file. I just added 'rm
> -f /var/lib/dbus/machine-id' to blend_finalize() and now the iso has a
> different machine-id on every boot.
> 
> If /etc/machine-id is missing, systemd-journald will fail. If the file
> is empty, it'll get a new number. (That doesn't concern us, but
> there's code for it in refractasnapshot because people use that on
> debian with systemd.)
> 

Thanks a lot for the analysis fsmithred. I guess we should open a bug
report against dbus to correct the behaviour of the dbus init script
(and ensure that /var/lib/dbus/machine-id is regenerated at each
boot).

On the other hand, it looks like /etc/machine-id mighr come from
Debian installations "converted" to Devuan, but we should check
whether any of the installer components might have put it there. We
should collect as many reports as possible of things that won't work
if /etc/machine-id does not exist.

Anybody willing to help with this: if your Devuan installation has a
file /etc/machine-id, could you please move/remove it and report any
application complaining about that, including the version of Devuan
you are using?

Thanks

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Adam Borowski]

On Fri, Mar 08, 2019 at 11:44:49AM -0600, Jamey Fletcher wrote:
> >> Not on this Debian Buster machine.  Both /var/lib/dbus/machine-id and
> >> /etc/machine-id have a date/time consistent with the initial system
> >> installation back in October.  The machine has been rebooted a number of
> >> times since.  I've not tried moving either and seeing what happens on
> >> the next system restart.

> I have it here on my Gentoo install - and /var/lib/dbus/machine-id is a
> symlink to it.  It's basically the same length as a MD5SUM - why not just
> standardize on the MD5SUM of an empty 0-byte file (
> d41d8cd98f00b204e9800998ecf8427e ) and tell them to take a running leap
> from the ISS?

This.

Let's give all that software a machine-id, and make it _consistent_!
In other words, I am Spartacus.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Jamey Fletcher]

> Anno domini 2019 Fri, 8 Mar 10:45:04 -0600

>  Nate Bargmann scripsit:

>> * On 2019 08 Mar 08:00 -0600, KatolaZ wrote:

>>> and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
>>> time. But we need to double-check.

>> Not on this Debian Buster machine.  Both /var/lib/dbus/machine-id and
>> /etc/machine-id have a date/time consistent with the initial system
>> installation back in October.  The machine has been rebooted a number of
>> times since.  I've not tried moving either and seeing what happens on
>> the next system restart.

> Hm ... same here:

> nik@t61:~$ ll /var/lib/dbus/machine-id
> -rw-r--r-- 1 root root 33 Sep 15  2015 /var/lib/dbus/machine-id
> nik@t61:~$ ll /etc/machine-id
> -r--r--r-- 1 root root 33 Sep 15  2015 /etc/machine-id
> nik@t61:~$

> 2015 ... that was jessie, when this computer was set up ...

I have it here on my Gentoo install - and /var/lib/dbus/machine-id is a
symlink to it.  It's basically the same length as a MD5SUM - why not just
standardize on the MD5SUM of an empty 0-byte file (
d41d8cd98f00b204e9800998ecf8427e ) and tell them to take a running leap
from the ISS?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Arnt Karlsen]

On Fri, 8 Mar 2019 15:46:26 +0100, Dr. wrote in message 
<201903081546.27040.dr.kl...@gmx.at>:

> Anno domini 2019 Fri, 8 Mar 13:15:48 +
>  Rowland Penny via Dng scripsit:
> > On Fri, 8 Mar 2019 13:47:40 +0100
> > Jaromil  wrote:
> >   
> > > 
> > > re all,
> > > 
> > > any thoughts about this new systemd-made thing that freedesktop
> > > immediately "standardized" (whatever is their procedure for that,
> > > likely smoking cigars among old-boys or so)
> > > https://www.freedesktop.org/software/systemd/man/machine-id.html
> > > 
> > > its easy to replace by a script of course that's not the problem
> > > (the manpage suggests to use a systemd application for that, not
> > > a joke!) but I'm curious if anyone has some background and
> > > thoughts about this
> > > 
> > > AFAIK chromium started checking it and its absence on Devuan
> > > Beowulf is reported as an error, so we may have to work around
> > > this.
> > > 
> > > but first things first: do we want /etc/machine-id? and how?
> > >   
> > 
> > I would have thought the first question is 'What is it used for ?'  
> 
> Surveillance, nothing else. IMO it would be nice to regenerate it
> every time the file is read.

..my /etc/cron.d/machine-id:
PATH=/bin:/usr/bin:/sbin:/usr/sbin

# ..a new /etc/machine-id every minute... ;o)
* * * * * root  date |md5sum |cut -d" " -f-1 >/etc/machine-id |tee
  >/dev/null 2>&1

...keeps e.g. chromium from whining about:
"[20478:20478:0307/101807.205617:ERROR:browser_dm_token_storage_linux.cc(101)]
Error: /etc/machine-id contains 0 characters (32 were expected)"

..dunno too much about what else they use to track us though...


..those nefarious web browsers should run _only_once_, between the
boot-up of the throw-away virtual machine it lives in, and the shut 
down and the throwing away of that throw-away virtual machine it
lived in.


> > I don't seem to have it and everything works without it.  
> 
> It's on my beowulf installations, and I didn't even know that it was
> there :-/

..quick starting point:
ll /proc/sys/kernel/random/boot_id /etc/hostid /etc/machine-id \
/var/lib/dbus/machine-id /var/db/dbus/machine-id


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[. fsmithred via Dng]

On 3/8/19, KatolaZ  wrote:
>
> Then we could probably just ignore it, right? It turns out I was
> making confusion between /etc/machine-id and
> /car/lib/dbus/machine-id. There is no /etc/machine-id in any of my
> machines, either on ascii or on beowulf, and I had forgotten you had
> pushed the patch to elogind to use the dbus machine-id instead.
>
> We should just double-check that the dbus machine-id is regenerated at
> reboot, as expected.
>

There's no /etc/machine-id in my beowulf that was an upgrade from
refracta ascii or in the beowulf live iso that I just made with
live-sdk.

Refractasnapshot excludes /var/lib/dbus/machine-id and blanks
/etc/machine-id if it's present.

Refractainstaller excludes /var/lib/dbus/machine-id and does nothing
with /etc/machine-id.

Isos made with live-sdk will have /var/lib/dbus/machine-id, and it's
the same number every boot unless we remove the file. I just added 'rm
-f /var/lib/dbus/machine-id' to blend_finalize() and now the iso has a
different machine-id on every boot.

If /etc/machine-id is missing, systemd-journald will fail. If the file
is empty, it'll get a new number. (That doesn't concern us, but
there's code for it in refractasnapshot because people use that on
debian with systemd.)

fsmithred
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Dr. Nikolaus Klepp]

Anno domini 2019 Fri, 8 Mar 10:45:04 -0600
 Nate Bargmann scripsit:
> * On 2019 08 Mar 08:00 -0600, KatolaZ wrote:
> > and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
> > time. But we need to double-check.
> 
> Not on this Debian Buster machine.  Both /var/lib/dbus/machine-id and
> /etc/machine-id have a date/time consistent with the initial system
> installation back in October.  The machine has been rebooted a number of
> times since.  I've not tried moving either and seeing what happens on
> the next system restart.
> 
> - Nate
> 

Hm ... same here:

nik@t61:~$ ll /var/lib/dbus/machine-id
-rw-r--r-- 1 root root 33 Sep 15  2015 /var/lib/dbus/machine-id
nik@t61:~$ ll /etc/machine-id
-r--r--r-- 1 root root 33 Sep 15  2015 /etc/machine-id
nik@t61:~$ 

2015 ... that was jessie, when this computer was set up ...

Nik

-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Nate Bargmann]

* On 2019 08 Mar 08:00 -0600, KatolaZ wrote:
> and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
> time. But we need to double-check.

Not on this Debian Buster machine.  Both /var/lib/dbus/machine-id and
/etc/machine-id have a date/time consistent with the initial system
installation back in October.  The machine has been rebooted a number of
times since.  I've not tried moving either and seeing what happens on
the next system restart.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: http://www.n0nb.us  GPG key: D55A8819  GitHub: N0NB


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[KatolaZ]

On Fri, Mar 08, 2019 at 02:08:39PM +, Mark Hindley wrote:
> On Fri, Mar 08, 2019 at 03:00:31PM +0100, KatolaZ wrote:
> > > Yes, elogind uses it. But I got upstream to take a patch which uses
> > > /var/lib/dbus/machine-id as an alternative to /etc/machine-id.
> > > 
> > 
> > and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
> > time. But we need to double-check.
> 
> Yes, but only if it is missing, so eg if /var/ is tmpfs or you arrange to 
> clear
> it.
> 
> /var/lib/dbus/machine-id is generated by a dbus-uuidgen(1) call in the dbus
> initscript. This doesn't overwrite an existing file so that the machine-id is
> not changed during a single uptime.
> 
> Certainly  elogind has no requirement for /etc/machine-id to be present or
> consistent between boots.

Then we could probably just ignore it, right? It turns out I was
making confusion between /etc/machine-id and
/car/lib/dbus/machine-id. There is no /etc/machine-id in any of my
machines, either on ascii or on beowulf, and I had forgotten you had
pushed the patch to elogind to use the dbus machine-id instead.

We should just double-check that the dbus machine-id is regenerated at
reboot, as expected.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Dr. Nikolaus Klepp]

Anno domini 2019 Fri, 8 Mar 13:15:48 +
 Rowland Penny via Dng scripsit:
> On Fri, 8 Mar 2019 13:47:40 +0100
> Jaromil  wrote:
> 
> > 
> > re all,
> > 
> > any thoughts about this new systemd-made thing that freedesktop
> > immediately "standardized" (whatever is their procedure for that,
> > likely smoking cigars among old-boys or so)
> > https://www.freedesktop.org/software/systemd/man/machine-id.html
> > 
> > its easy to replace by a script of course that's not the problem (the
> > manpage suggests to use a systemd application for that, not a joke!)
> > but I'm curious if anyone has some background and thoughts about this
> > 
> > AFAIK chromium started checking it and its absence on Devuan Beowulf
> > is reported as an error, so we may have to work around this.
> > 
> > but first things first: do we want /etc/machine-id? and how?
> > 
> 
> I would have thought the first question is 'What is it used for ?'

Surveillance, nothing else. IMO it would be nice to regenerate it every time 
the file is read.

> I don't seem to have it and everything works without it.

It's on my beowulf installations, and I didn't even know that it was there :-/

Nik

> 
> Rowland
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Mark Hindley]

On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote:
> Jaromil,
> 
> this is currently managed by eudev in devuan and, IIRC, it is simply
> regenerated as a random ID at each boot. I guess it's still there
> because it is used by several things, including
> session-management-related stuff. We had a discussion on IRC with Mark
> (LeePen) about that several weeks ago, and IIRC we concluded that
> keeping it around but re-generating it at boot was the way to avoid
> breakage.

Yes, elogind uses it. But I got upstream to take a patch which uses
/var/lib/dbus/machine-id as an alternative to /etc/machine-id.

Mark
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Mark Hindley]

On Fri, Mar 08, 2019 at 03:00:31PM +0100, KatolaZ wrote:
> > Yes, elogind uses it. But I got upstream to take a patch which uses
> > /var/lib/dbus/machine-id as an alternative to /etc/machine-id.
> > 
> 
> and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
> time. But we need to double-check.

Yes, but only if it is missing, so eg if /var/ is tmpfs or you arrange to clear
it.

/var/lib/dbus/machine-id is generated by a dbus-uuidgen(1) call in the dbus
initscript. This doesn't overwrite an existing file so that the machine-id is
not changed during a single uptime.

Certainly  elogind has no requirement for /etc/machine-id to be present or
consistent between boots.

Mark
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[info at smallinnovations dot nl]

On 08-03-19 14:23, KatolaZ wrote:
> On Fri, Mar 08, 2019 at 01:47:40PM +0100, Jaromil wrote:
>> re all,
>>
>> any thoughts about this new systemd-made thing that freedesktop
>> immediately "standardized" (whatever is their procedure for that,
>> likely smoking cigars among old-boys or so)
>> https://www.freedesktop.org/software/systemd/man/machine-id.html
>>
>> its easy to replace by a script of course that's not the problem (the
>> manpage suggests to use a systemd application for that, not a joke!)
>> but I'm curious if anyone has some background and thoughts about this
>>
>> AFAIK chromium started checking it and its absence on Devuan Beowulf
>> is reported as an error, so we may have to work around this.
>>
>> but first things first: do we want /etc/machine-id? and how?
>>
> Jaromil,
>
> this is currently managed by eudev in devuan and, IIRC, it is simply
> regenerated as a random ID at each boot. I guess it's still there
> because it is used by several things, including
> session-management-related stuff. We had a discussion on IRC with Mark
> (LeePen) about that several weeks ago, and IIRC we concluded that
> keeping it around but re-generating it at boot was the way to avoid
> breakage.
>
> Any thoughts on the matter are appreciated, but concrete insight on
> the ins and outs are much more useful I guess (read: please let's
> avoid a useless uninformed flame about that :P).
>
> My2Cents
>
> KatolaZ
>
I opened the link and read:

- that it should replace the POSIX gethostid(3) call,
- that it should be unique,
- should be confidential
- and last but not least it is supplemental to D-Bus machine ID.
/var/lib/dbus/machine-id could even be a symlink to /etc/machine-id

Besides the possibility to network boot with the systemd.machine_id= 
kernel commandline i do not see any advantage to user of
systemadministrator. I do see the possibilities to abuse it and the only
reason for existing i can think of is DRM or surveillance.

If this is  flaming, so be it.

Grtz.

Nick




signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[KatolaZ]

On Fri, Mar 08, 2019 at 01:49:20PM +, Mark Hindley wrote:
> On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote:
> > Jaromil,
> > 
> > this is currently managed by eudev in devuan and, IIRC, it is simply
> > regenerated as a random ID at each boot. I guess it's still there
> > because it is used by several things, including
> > session-management-related stuff. We had a discussion on IRC with Mark
> > (LeePen) about that several weeks ago, and IIRC we concluded that
> > keeping it around but re-generating it at boot was the way to avoid
> > breakage.
> 
> Yes, elogind uses it. But I got upstream to take a patch which uses
> /var/lib/dbus/machine-id as an alternative to /etc/machine-id.
> 

and, IIRC, also /var/lib/dbus/machine-id is re-generated at boot
time. But we need to double-check.

Thanks Mark

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[karl]

Jaromil:
> any thoughts about this new systemd-made thing that freedesktop
> immediately "standardized" (whatever is their procedure for that,
> likely smoking cigars among old-boys or so)
> https://www.freedesktop.org/software/systemd/man/machine-id.html
...

. It doesn't say "why".
  Why should I (we) provide a means to uniquely identify my systems ?
  I don't need it. Is it for
  - the nice though not useful concept, yes we reinvent things you know
  - the ongoing trend for more surveillance from the authorities
  - the ongoing trend for more surveillance from the advertising firms
  - the ongoing trend for more surveillance for "copyright" reason

. It says "This ID uniquely identifies the host."
  - on the lan I can just as well use hostname or the primary ip-number
  - on the internet I use the fqdn or the ip-number
  The uniqness part will fail without someone guarantying the uniqness.
  Do we have an "IEEE handling out oui's" - for machine-id's ?
  Even if there were some IEEE, pci- or usb-consortium handling out vendor 
  parts of the id's, there is no guaranty for uniqness since that 
  number is just what's the local admin fancies, or is it for 
  "tamperproof" hardware, something oppressive regimes would like.
  And I have seen pci cards with the wrong vendor part: "the programmer
  left and we don't have the code so we cannot change it" as the vendor
  put it.

> AFAIK chromium started checking it and its absence on Devuan Beowulf
> is reported as an error, so we may have to work around this.

Isn't that a bug, the above man page says:
  It should be considered "confidential", and must not be exposed in
  untrusted environments, in particular on the network. 
Why would a network centric program need this unless it wants to
expose it ?

> but first things first: do we want /etc/machine-id? and how?

In my view it falls in the completely unnessesary or the potentially
dangerous group.

I don't want it.

Regards,
/Karl Hammar


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Adam Borowski]

On Fri, Mar 08, 2019 at 02:23:20PM +0100, KatolaZ wrote:
> > but first things first: do we want /etc/machine-id? and how?

> this is currently managed by eudev in devuan and, IIRC, it is simply
> regenerated as a random ID at each boot.

> we concluded that keeping it around but re-generating it at boot was the
> way to avoid breakage.

And I say you're 100% right here.

The machine-id:
* is a privacy issue
* gets broken when cloned systems are involved
but defusing it by re-generating every boot works around both of the above
while requiring no patches to affected software.

> Any thoughts on the matter are appreciated, but concrete insight on
> the ins and outs are much more useful I guess (read: please let's
> avoid a useless uninformed flame about that :P).

Be realistic... avoiding an uninformed flame would be against our rules :)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[KatolaZ]

On Fri, Mar 08, 2019 at 01:47:40PM +0100, Jaromil wrote:
> 
> re all,
> 
> any thoughts about this new systemd-made thing that freedesktop
> immediately "standardized" (whatever is their procedure for that,
> likely smoking cigars among old-boys or so)
> https://www.freedesktop.org/software/systemd/man/machine-id.html
> 
> its easy to replace by a script of course that's not the problem (the
> manpage suggests to use a systemd application for that, not a joke!)
> but I'm curious if anyone has some background and thoughts about this
> 
> AFAIK chromium started checking it and its absence on Devuan Beowulf
> is reported as an error, so we may have to work around this.
> 
> but first things first: do we want /etc/machine-id? and how?
> 

Jaromil,

this is currently managed by eudev in devuan and, IIRC, it is simply
regenerated as a random ID at each boot. I guess it's still there
because it is used by several things, including
session-management-related stuff. We had a discussion on IRC with Mark
(LeePen) about that several weeks ago, and IIRC we concluded that
keeping it around but re-generating it at boot was the way to avoid
breakage.

Any thoughts on the matter are appreciated, but concrete insight on
the ins and outs are much more useful I guess (read: please let's
avoid a useless uninformed flame about that :P).

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] new freedesktop "standard": /etc/machine-id

[Rowland Penny via Dng]

On Fri, 8 Mar 2019 13:47:40 +0100
Jaromil  wrote:

> 
> re all,
> 
> any thoughts about this new systemd-made thing that freedesktop
> immediately "standardized" (whatever is their procedure for that,
> likely smoking cigars among old-boys or so)
> https://www.freedesktop.org/software/systemd/man/machine-id.html
> 
> its easy to replace by a script of course that's not the problem (the
> manpage suggests to use a systemd application for that, not a joke!)
> but I'm curious if anyone has some background and thoughts about this
> 
> AFAIK chromium started checking it and its absence on Devuan Beowulf
> is reported as an error, so we may have to work around this.
> 
> but first things first: do we want /etc/machine-id? and how?
> 

I would have thought the first question is 'What is it used for ?'

I don't seem to have it and everything works without it.

Rowland
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] new freedesktop "standard": /etc/machine-id

[Jaromil]

re all,

any thoughts about this new systemd-made thing that freedesktop
immediately "standardized" (whatever is their procedure for that,
likely smoking cigars among old-boys or so)
https://www.freedesktop.org/software/systemd/man/machine-id.html

its easy to replace by a script of course that's not the problem (the
manpage suggests to use a systemd application for that, not a joke!)
but I'm curious if anyone has some background and thoughts about this

AFAIK chromium started checking it and its absence on Devuan Beowulf
is reported as an error, so we may have to work around this.

but first things first: do we want /etc/machine-id? and how?

ciao


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] simple-netaid-backend debugged.

[Daniel Abrecht via Dng]

On 2019-03-07 19:49, Alessandro Selli wrote:

Next improvement would be using current commands (ip and iw) in place
of the obsolete and deprecated ones, i.e. ifconfig and iwconfig:


ifconfig and iwconfig being depracted or obsolete is questionable at 
best. They work, get security patches if they need them, provide a 
stable interface, and have a stable, parseable output that's known to 
not change.


ip and iw on the other hand, well, they aren't suitable to pass 
networking information to other programs because they have a less stable 
interface. At least with ip, that will get a bit better with the -json 
option. But that option isn't in debians version yet.


In addition to this, ifconfig and iwconfig will also work on other unix 
systems, such as FreeBSD.


Parsing output in regular programs is more of a hack anyway. Why can't 
these tools provide a library for use in regular programs?


There is also the option of using the kernel interfaces directly, but 
then the program directly depends on linux.


There really is no good option.


PS: It's not like I don't use ip at all, I do use it's netns feature on 
one of my servers to move all it's network interfaces to a different 
netns, which I then use for a libvirt container, in which I setup the 
routing between the host system, the containers, and the VMs on my 
server. There is no reason why ip should do this and not a dedicated 
program though.


I think about using network namespaces, and maybe also some filesystem & 
user namespaces on my desktop PC too at some point. I could probably 
write a pam module to isolate user homes further and put different users 
into different network namespaces. That way, I could make sure all 
connections of certain users are part of my regular network, and all 
connections of another users are always routed over a vpn, a proxy, over 
tor, or something similar. But I won't be able to use ip for that. And I 
won't get to that any time soon, there is just so much stuff to do. But 
linux namespaces are really awesome, I use them all the time, and not 
just for containers.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng