armv7 vs buster problem #3

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

armv7 vs buster problem #3

Gene Heskett-4
How do I set the domainname so it sticks over a reboot?

Thanks a bunch.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: armv7 vs buster problem #3

Andreas Jellinghaus-3
domainname as in NIS? no idea.

domainname as in fqdn hostname?

echo $fqdn > /etc/hostname
echo 127.0.0.1 $fqdn localhost > /etc/hosts

works for me, and I hasn't been changed in years. Not sure if systemd will change something about this though.

Andreas

Am Mi., 3. Juli 2019 um 21:17 Uhr schrieb Gene Heskett <[hidden email]>:
How do I set the domainname so it sticks over a reboot?

Thanks a bunch.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: armv7 vs buster problem #3

Gene Heskett-4
On Wednesday 03 July 2019 16:00:53 Andreas Jellinghaus wrote:

> domainname as in NIS? no idea.
>
> domainname as in fqdn hostname?
domainname portion of a fqdn, same as in the host file. I can set it by
the usual means, its there till I reboot, then its back to (none)
>
> echo $fqdn > /etc/hostname
> echo 127.0.0.1 $fqdn localhost > /etc/hosts
>
> works for me, and I hasn't been changed in years. Not sure if systemd
> will change something about this though.

Just one of the things its taken over. Now we have a different command to
set the hostname too if you want it to stick over a reboot.  Someone a
couple weeks ago showed me how to do that for hostname only. I've no
clue how it does that because it can do it even if /etc/hostname has
been made immutable. In fact I'd call that a major security breech.

> Andreas
>
> Am Mi., 3. Juli 2019 um 21:17 Uhr schrieb Gene Heskett
> <[hidden email]
>
> > How do I set the domainname so it sticks over a reboot?
> >
> > Thanks a bunch.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: armv7 vs buster problem #3

John Paul Adrian Glaubitz
Hi Gene!

On 7/3/19 10:42 PM, Gene Heskett wrote:
> Just one of the things its taken over. Now we have a different command to
> set the hostname too if you want it to stick over a reboot.  Someone a
> couple weeks ago showed me how to do that for hostname only. I've no
> clue how it does that because it can do it even if /etc/hostname has
> been made immutable. In fact I'd call that a major security breech.

Could you move this discussion over to the debian-user mailing list?
As already mentioned by Reco earlier, those questions aren't specific
to ARM.

As for systemd and related stuff, I would recommend reading through the
documentation a bit which explains a lot of these things. I think you
will make faster progress by understanding the concepts rather than asking
for every single problem you are running into.

Regarding why systemd has its own hostname command is simple: The original
Unix hostname command doesn't set the hostname persistently (you had write
the file yourself) and you had to reboot the machine to make sure the new
hostname was propagated everywhere across the system (after writing the file)
which is no longer the case with systemd where these changes are propagated
using dbus which the old hostname command didn't support [1].

The new systemd hostnamectl makes sure other processes are immediately
notified if the hostname gets changed and I think that's something
reasonable to expect. With the old approach, it could happen that after
issuing the hostname command to rename the host, that some processes
still saw the old hostname, so the system got into an inconsistent
state.

In most cases where systemd provides its own solution for a certain feature,
there are actually pretty good technical reasons why that was done. In most
cases, it was necessary because the old Unix version of a command was rather
limited in functionality or had certain design problems.

Adrian

> [1] https://blog.fpmurphy.com/2014/10/revisiting-the-systemd-d-bus-interface.html

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: armv7 vs buster problem #3

Gene Heskett-4
On Wednesday 03 July 2019 18:06:18 John Paul Adrian Glaubitz wrote:

> Hi Gene!
>
> On 7/3/19 10:42 PM, Gene Heskett wrote:
> > Just one of the things its taken over. Now we have a different
> > command to set the hostname too if you want it to stick over a
> > reboot.  Someone a couple weeks ago showed me how to do that for
> > hostname only. I've no clue how it does that because it can do it
> > even if /etc/hostname has been made immutable. In fact I'd call that
> > a major security breech.
>
> Could you move this discussion over to the debian-user mailing list?
> As already mentioned by Reco earlier, those questions aren't specific
> to ARM.
>
> As for systemd and related stuff, I would recommend reading through
> the documentation a bit which explains a lot of these things. I think
> you will make faster progress by understanding the concepts rather
> than asking for every single problem you are running into.
>
> Regarding why systemd has its own hostname command is simple: The
> original Unix hostname command doesn't set the hostname persistently
> (you had write the file yourself)

Six of one, half dozen of the other. In the former case eeryone knew you
had to call up nano and edit the hostname into /etc/hostname.  Now we
have a new method that isn't even fixed by a reboot according to sudo.  
And whats the hands down most popular command in the day or so it takes
ti sort the basket of rattlesnakes the installer hands you ? sudo of
course.

> and you had to reboot the machine to
> make sure the new hostname was propagated everywhere across the system
> (after writing the file) which is no longer the case with systemd
> where these changes are propagated using dbus which the old hostname
> command didn't support [1].
>
> The new systemd hostnamectl makes sure other processes are immediately
> notified if the hostname gets changed and I think that's something
> reasonable to expect.

IF, note all caps, then why does sudo bitch so much?

> With the old approach, it could happen that
> after issuing the hostname command to rename the host, that some
> processes still saw the old hostname, so the system got into an
> inconsistent state.
>
> In most cases where systemd provides its own solution for a certain
> feature, there are actually pretty good technical reasons why that was
> done. In most cases, it was necessary because the old Unix version of
> a command was rather limited in functionality or had certain design
> problems.
>
If it is supposed to tell everything that the hostname has changed, it
has a huge bug because it didn't tell sudo.
> Adrian
>
> > [1]
> >
https://blog.fpmurphy.com/2014/10/revisiting-the-systemd-d-bus-interface.html


Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: armv7 vs buster problem #3

Gene Heskett-4
In reply to this post by John Paul Adrian Glaubitz
On Wednesday 03 July 2019 18:06:18 John Paul Adrian Glaubitz wrote:

> Hi Gene!
>
> On 7/3/19 10:42 PM, Gene Heskett wrote:
> > Just one of the things its taken over. Now we have a different
> > command to set the hostname too if you want it to stick over a
> > reboot.  Someone a couple weeks ago showed me how to do that for
> > hostname only. I've no clue how it does that because it can do it
> > even if /etc/hostname has been made immutable. In fact I'd call that
> > a major security breech.
>
> Could you move this discussion over to the debian-user mailing list?
> As already mentioned by Reco earlier, those questions aren't specific
> to ARM.
>
> As for systemd and related stuff, I would recommend reading through
> the documentation a bit which explains a lot of these things. I think
> you will make faster progress by understanding the concepts rather
> than asking for every single problem you are running into.
>
> Regarding why systemd has its own hostname command is simple: The
> original Unix hostname command doesn't set the hostname persistently
> (you had write the file yourself) and you had to reboot the machine to
> make sure the new hostname was propagated everywhere across the system
> (after writing the file) which is no longer the case with systemd
> where these changes are propagated using dbus which the old hostname
> command didn't support [1].
>
> The new systemd hostnamectl makes sure other processes are immediately
> notified if the hostname gets changed and I think that's something
> reasonable to expect. With the old approach, it could happen that
> after issuing the hostname command to rename the host, that some
> processes still saw the old hostname, so the system got into an
> inconsistent state.
>
> In most cases where systemd provides its own solution for a certain
> feature, there are actually pretty good technical reasons why that was
> done. In most cases, it was necessary because the old Unix version of
> a command was rather limited in functionality or had certain design
> problems.
>
> Adrian
>
> > [1]
> > https://blog.fpmurphy.com/2014/10/revisiting-the-systemd-d-bus-inter
> >face.html

I read/scanned thru this 2 or 3 times without finding any clues to fix
what ails this install, I suspect from the dates of that thread, its 5+
years too old.

But it does give me hope that there are good answers out there,
someplace...

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>