Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #166637 > unrolled thread

change hostname & static IP & ???

Back to article view | Back to linux.debian.user

Contents

  change hostname & static IP & ??? ken <gebser@mousecar.com> - 2016-04-12 01:10 +0200
    Re: change hostname & static IP & ??? David Wright <deblis@lionunicorn.co.uk> - 2016-04-12 03:40 +0200
      Re: change hostname & static IP & ??? <tomas@tuxteam.de> - 2016-04-12 09:30 +0200
        Re: change hostname & static IP & ??? ken <gebser@mousecar.com> - 2016-04-12 23:30 +0200
          Re: change hostname & static IP & ??? David Wright <deblis@lionunicorn.co.uk> - 2016-04-13 02:40 +0200
          Re: change hostname & static IP & ??? <tomas@tuxteam.de> - 2016-04-13 09:50 +0200
      Clone SD card for new system <- Re: change hostname & static IP & ??? ken <gebser@mousecar.com> - 2016-04-12 16:30 +0200
        Re: Clone SD card for new system <- Re: change hostname & static IP  & ??? David Wright <deblis@lionunicorn.co.uk> - 2016-04-13 02:10 +0200
    Re: [Raspbian-devel] change hostname & static IP & ??? Stian Skjelstad <stian@barnfind.no> - 2016-04-12 09:40 +0200

#166637 — change hostname & static IP & ???

[Multipart message — attachments visible in raw view] — view raw

This is on Wheezy for a Raspberry Pi.

Using dd, I copied the SD card for one (nicely working and configured) 
system onto another SD card.  I want to use this second card for another 
system, so need to change the hostname and (static) IP address.  
Yesterday I grepped the whole system for one and then the other and 
where I found either, I made appropriate changes (i.e., previous 
hostname to new hostname, previous IP address to new IP address).  I 
also zeroed out all text-based files in /var/log/ (e.g., >messages), 
just to start the new system with clean logs.

Both the previous (still running) system and the new one (not yet 
running) are to be on the same LAN, so I'm pretty certain that no other 
networking configuration-- like broadcast or netmask-- needs to be 
touched (how could it need any?).

Neither of these systems has any public-facing services currently running.

My concerns are these:

Only files which grep could find were amended. (Note that grep was run 
on the card when it was mounted on another system, not when the system 
on that card was booted and running.)  Is there a file of some kind, 
perhaps, which encodes either the hostname and/or IP address in such a 
way that would hide it/them from grep?

Since people are supposed to be able (I think, never done) to take an SD 
out of one RPi and put and boot it in another RPi (with the same 
hardware), I didn't make any attempt to find and change any hardware 
designations, like the MAC address of the NIC.  Is that okay?

Is there anything I'm missing or forgetting?


tia for fullohelp tips.

[toc] | [next] | [standalone]

#166640

On Mon 11 Apr 2016 at 19:02:45 (-0400), ken wrote:
> This is on Wheezy for a Raspberry Pi.
> 
> Using dd, I copied the SD card for one (nicely working and
> configured) system onto another SD card.  I want to use this second
> card for another system, so need to change the hostname and (static)
> IP address.  Yesterday I grepped the whole system for one and then
> the other and where I found either, I made appropriate changes
> (i.e., previous hostname to new hostname, previous IP address to new
> IP address).  I also zeroed out all text-based files in /var/log/
> (e.g., >messages), just to start the new system with clean logs.
> 
> Both the previous (still running) system and the new one (not yet
> running) are to be on the same LAN, so I'm pretty certain that no
> other networking configuration-- like broadcast or netmask-- needs
> to be touched (how could it need any?).
> 
> Neither of these systems has any public-facing services currently running.
> 
> My concerns are these:
> 
> Only files which grep could find were amended. (Note that grep was
> run on the card when it was mounted on another system, not when the
> system on that card was booted and running.)  Is there a file of
> some kind, perhaps, which encodes either the hostname and/or IP
> address in such a way that would hide it/them from grep?

If you regenerate ssh keys, your .ssh/known_hosts files will have
hostnames and IP numbers you might want to remove. They're encrypted.
You could blank them like the log files.

The key pairs themselves only have visible hostnames in the public
part's file.

> Since people are supposed to be able (I think, never done) to take
> an SD out of one RPi and put and boot it in another RPi (with the
> same hardware), I didn't make any attempt to find and change any
> hardware designations, like the MAC address of the NIC.  Is that
> okay?

Your router may know IP#/MAC combinations for dhcp.

Also IPv6 link-local addresses are generated from the MAC address
(in case you've told them to any of your other machines).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#166643

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Apr 11, 2016 at 08:31:16PM -0500, David Wright wrote:
> On Mon 11 Apr 2016 at 19:02:45 (-0400), ken wrote:
> > This is on Wheezy for a Raspberry Pi.
> > 
> > Using dd, I copied the SD card for one (nicely working and
> > configured) system onto another SD card [...]

> .ssh/known_hosts [...]

Also, your new host will have the same ssh host private key. This
might or might not annoy you.

> Your router may know IP#/MAC combinations for dhcp.
> 
> Also IPv6 link-local addresses are generated from the MAC address
> (in case you've told them to any of your other machines).

Another thing to look out for:

Bits and pieces of your /etc might end up in your initramfs,
namely those needed in early boot (e.g. things needed to
bring up the root file system). The static IP address might
be needed if you have your root on NFS, for example. Or
the /etc/crypttab, if you're running with encrypted root
(I don't think so, but I lost myself some hair over this
one).

So after you have "fixed up" your SD card clone (IPs and all
that things) you might want to run update-initramfs for those
bits to find their way into the initramfs.   

Beware that now you have two different file systems with
the same UUID. This might confuse some all too credulous
programs that rely on (re-) seeing the same medium if the
UUID didn't change.

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlcMo2oACgkQBcgs9XrR2kbPqACdGHG1Q3Ze1yLyVM4UabHumZdY
6OoAn1c1YPrEhEu3h9v11oepDY9gYpu0
=sEdO
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#166668

[Multipart message — attachments visible in raw view] — view raw

On 04/12/2016 03:27 AM, tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, Apr 11, 2016 at 08:31:16PM -0500, David Wright wrote:
>> On Mon 11 Apr 2016 at 19:02:45 (-0400), ken wrote:
>>> This is on Wheezy for a Raspberry Pi.
>>>
>>> Using dd, I copied the SD card for one (nicely working and
>>> configured) system onto another SD card [...]
>> .ssh/known_hosts [...]
> Also, your new host will have the same ssh host private key. This
> might or might not annoy you.

You mean those /etc/ssh/ssh_host_*key* files, yes?


> Another thing to look out for:
>
> Bits and pieces of your /etc might end up in your initramfs,
> namely those needed in early boot (e.g. things needed to
> bring up the root file system). The static IP address might
> be needed if you have your root on NFS, for example. Or
> the /etc/crypttab, if you're running with encrypted root
> (I don't think so, but I lost myself some hair over this
> one).
>
> So after you have "fixed up" your SD card clone (IPs and all
> that things) you might want to run update-initramfs for those
> bits to find their way into the initramfs.

Thanks for letting me know.  Though I've set up a few encrypted file 
systems and compiled lots of kernels in the past, still I'm a 
feets-pointing-backwards idiot when it comes to initramfs, never needed 
to know much about it,

It sounds like "update-initramfs -v -u all" should be the last thing I 
do before the initial reboot, yes?


> Beware that now you have two different file systems with
> the same UUID. This might confuse some all too credulous
> programs that rely on (re-) seeing the same medium if the
> UUID didn't change.

Very good to know... and I didn't know that at all.  A quick look around 
found me dbus-uuidgen, a command to create a new uuid.  It's stored in 
/var/lib/dbus/machine-id says the manpage... and confirmed.  Is that the 
UUID you're referring to?

The manpage makes this one seem easy...

cd [the SD card's / mount point]
dbus-uuidgen > var/lib/dbus/machine-id


There are also things called UUIDs, or 'labels', for devices and for 
partitions and for swap(s).  Do I need to do something with them as well?

[toc] | [prev] | [next] | [standalone]

#166674

On Tue 12 Apr 2016 at 17:28:14 (-0400), ken wrote:
> On 04/12/2016 03:27 AM, tomas@tuxteam.de wrote:
> >On Mon, Apr 11, 2016 at 08:31:16PM -0500, David Wright wrote:
> >>On Mon 11 Apr 2016 at 19:02:45 (-0400), ken wrote:
> >>>This is on Wheezy for a Raspberry Pi.
> >>>
> >>>Using dd, I copied the SD card for one (nicely working and
> >>>configured) system onto another SD card [...]

> It sounds like "update-initramfs -v -u all" should be the last thing
> I do before the initial reboot, yes?
> 
> 
> >Beware that now you have two different file systems with
> >the same UUID. This might confuse some all too credulous
> >programs that rely on (re-) seeing the same medium if the
> >UUID didn't change.
> 
> Very good to know... and I didn't know that at all.  A quick look
> around found me dbus-uuidgen, a command to create a new uuid.  It's
> stored in /var/lib/dbus/machine-id says the manpage... and
> confirmed.  Is that the UUID you're referring to?
> 
> The manpage makes this one seem easy...
> 
> cd [the SD card's / mount point]
> dbus-uuidgen > var/lib/dbus/machine-id

Not that one, but that's worth doing (assuming that the mount point is
not / itself). But you need to remove machine-id first or nothing
may happen.

> There are also things called UUIDs, or 'labels', for devices and for
> partitions and for swap(s).  Do I need to do something with them as
> well?

Yes, what you see when you type
$ ls -l /dev/disk/by*
Whether they matter depends if you're using them or not (though
it's bad form to have duplicates). For unencrypted filesystems,
the contents of /etc/fstab will show how you're selecting filesystems
to mount.

If you created your _partitions_ on the clone independently from the
original (ie you dd'd /dev/sdc1 for example), then the partition
UUIDs will differ. But if you dd'd the entire card (as /dev/sdc for
example), then the partition UUIDs (partuuids) will also be
duplicated.

In both cases, the filesystem UUIDs will have been duplicated; those
are the ones in /dev/disk/by-uuid/ which are used by /etc/fstab if
the latter contains lines starting with UUID=. Grub also picks
these up when it writes a new /boot/grub/grub.cfg.
The same applies to /dev/disk/by-label and LABEL= if you use those.
(Grub doesn't.)

tune2fs will let you change the UUID and LABEL on ext filesystems.
I use gdisk to create partitions, and that handles partition UUIDs
(called GUIDs) and disk GUIDs. I think that becomes important with
encrypted disks, but others may need to help you there.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#166678

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Apr 12, 2016 at 05:28:14PM -0400, ken wrote:
> On 04/12/2016 03:27 AM, tomas@tuxteam.de wrote:

[Dave already gave pretty insightful answers]

> >Also, your new host will have the same ssh host private key. This
> >might or might not annoy you.
> 
> You mean those /etc/ssh/ssh_host_*key* files, yes?

Yes, exactly those. If you are "replacing" one installation by
another, you usually want to keep that, to keep clients from
freaking out that the "host key" has changed. Having two
"different"[1] host with the same key might confuse the hell
out of a sysadmin.

> >Another thing to look out for:
> >
> >Bits and pieces of your /etc might end up in your initramfs,
> [...]

> Thanks for letting me know.  Though I've set up a few encrypted file
> systems and compiled lots of kernels in the past, still I'm a
> feets-pointing-backwards idiot when it comes to initramfs, never
> needed to know much about it,

So am I -- didn't I mention I lost some hair over that ;-)

> It sounds like "update-initramfs -v -u all" should be the last thing
> I do before the initial reboot, yes?

Yes -- after chasing down the relevant (to your installation) bits and
pieces of /etc.

> >Beware that now you have two different file systems with
> >the same UUID [...]

> Very good to know... and I didn't know that at all.  A quick look
> around found me dbus-uuidgen, a command to create a new uuid.  It's
> stored in /var/lib/dbus/machine-id says the manpage... and
> confirmed.  Is that the UUID you're referring to?
> 
> The manpage makes this one seem easy...
> 
> cd [the SD card's / mount point]
> dbus-uuidgen > var/lib/dbus/machine-id
> 
> 
> There are also things called UUIDs, or 'labels', for devices and for
> partitions and for swap(s).  Do I need to do something with them as
> well?

Uh -- sorry: I actually meant the "file system label", which is nowadays
mostly implemented as an UUID (except for DOS FAT file systems, which
have very little room for the label).

I never tried, but strange things might occur if you insert both SD
cards at the same time in one computer (e.g. to copy over things),
at least depending on how many layers of "desktop goodness" try to
be helpful and get their feet tangled with two file systems with the
same label. What does end up in /dev/disk/by-uuid? The last one
mounted? What happens when you eject that one? The other before
the last one? Perhaps it's specced somewhere, but it's one of those
dark corners where you might expect software doing funny things.

Last time I looked, for example, the Gnome machinery for attaching
little things to the files in the file browser (hearts, stars, what
have you) indexed removable media by their label. Putting a heart
on one SD card could very well let a heart appear on a file with
the same path on the other SD card. Magic?

Things like that.

[1] "The same host" and "different hosts" gets complicated once
   you think of replacing the hardware after a catastrophe (loosely
   "bare metal recovery") or high availability takeover.

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlcN+aIACgkQBcgs9XrR2kbOVACeNt5am2a0JJ9JfkRwxL48CWhh
WFUAninw1UylMeNPAZldsKhgdNATViAv
=RRu+
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#166656 — Clone SD card for new system <- Re: change hostname & static IP & ???

[Multipart message — attachments visible in raw view] — view raw

On 04/11/2016 09:31 PM, David Wright wrote:
> On Mon 11 Apr 2016 at 19:02:45 (-0400), ken wrote:
>> This is on Wheezy for a Raspberry Pi.
>>
>> Using dd, I copied the SD card for one (nicely working and
>> configured) system onto another SD card.  I want to use this second
>> card for another system, so need to change the hostname and (static)
>> IP address.  Yesterday I grepped the whole system for one and then
>> the other and where I found either, I made appropriate changes
>> (i.e., previous hostname to new hostname, previous IP address to new
>> IP address).  I also zeroed out all text-based files in /var/log/
>> (e.g., >messages), just to start the new system with clean logs.
>>
>> Both the previous (still running) system and the new one (not yet
>> running) are to be on the same LAN, so I'm pretty certain that no
>> other networking configuration-- like broadcast or netmask-- needs
>> to be touched (how could it need any?).
>>
>> Neither of these systems has any public-facing services currently running.
>>
>> My concerns are these:
>>
>> Only files which grep could find were amended. (Note that grep was
>> run on the card when it was mounted on another system, not when the
>> system on that card was booted and running.)  Is there a file of
>> some kind, perhaps, which encodes either the hostname and/or IP
>> address in such a way that would hide it/them from grep?
> If you regenerate ssh keys, your .ssh/known_hosts files will have
> hostnames and IP numbers you might want to remove. They're encrypted.
> You could blank them like the log files.
>
> The key pairs themselves only have visible hostnames in the public
> part's file.

Ah, yes!  Thanks.  Some brain cells knew that, but were sleeping.  But 
actually I want to keep that ~/.ssh/known_hosts so I can ssh from this 
new RPi to the other machines on my LAN without having to reconfigure 
all that ssh stuff... one of the several time-saving reasons I'm 
(quasi-)duplicating the SD card.

But you bring up a very good point: I don't want the new system to have 
the same /etc/ssh/ssh_host_*key* files that the previous system has.  
Though it might work okay, still I think the sshd host keys are meant to 
be unique across all LAN'd systems (ideally unique in the universe).  So 
I think I need to do "rm etc/ssh/ssh_host_*key*" so that sshd knows 
they're gone; in the past IIRC these host keys were automatically 
created, probably done in the sshd script under init.d;  I hope that 
it's the same under the new-fangled systemd code.


>> Since people are supposed to be able (I think, never done) to take
>> an SD out of one RPi and put and boot it in another RPi (with the
>> same hardware), I didn't make any attempt to find and change any
>> hardware designations, like the MAC address of the NIC.  Is that
>> okay?
>>
>> Your router may know IP#/MAC combinations for dhcp.

I'm not using dhcpd on the router, so that won't affect me. But for 
those who do, if you can do "arp -a" on your router, that will show 
which MAC addresses are cached; "arp -d address" will delete that 
address's entry in the arp table, allowing/obligating the system to 
generate a/the new entry.


>>
>> Also IPv6 link-local addresses are generated from the MAC address
>> (in case you've told them to any of your other machines).

Again, not using that, but others may, so find the info useful.  Thanks.


>>
>> Cheers,
>> David.
>>

[toc] | [prev] | [next] | [standalone]

#166672 — Re: Clone SD card for new system <- Re: change hostname & static IP & ???

On Tue 12 Apr 2016 at 10:28:54 (-0400), ken wrote:
> On 04/11/2016 09:31 PM, David Wright wrote:
> >On Mon 11 Apr 2016 at 19:02:45 (-0400), ken wrote:
> >>This is on Wheezy for a Raspberry Pi.
> >>
> >>Using dd, I copied the SD card for one (nicely working and
> >>configured) system onto another SD card.  I want to use this second
> >>card for another system, so need to change the hostname and (static)
> >>IP address.  Yesterday I grepped the whole system for one and then
> >>the other and where I found either, I made appropriate changes
> >>(i.e., previous hostname to new hostname, previous IP address to new
> >>IP address).  I also zeroed out all text-based files in /var/log/
> >>(e.g., >messages), just to start the new system with clean logs.
> >>
> >>Both the previous (still running) system and the new one (not yet
> >>running) are to be on the same LAN, so I'm pretty certain that no
> >>other networking configuration-- like broadcast or netmask-- needs
> >>to be touched (how could it need any?).
> >>
> >>Neither of these systems has any public-facing services currently running.
> >>
> >>My concerns are these:
> >>
> >>Only files which grep could find were amended. (Note that grep was
> >>run on the card when it was mounted on another system, not when the
> >>system on that card was booted and running.)  Is there a file of
> >>some kind, perhaps, which encodes either the hostname and/or IP
> >>address in such a way that would hide it/them from grep?
> >If you regenerate ssh keys, your .ssh/known_hosts files will have
> >hostnames and IP numbers you might want to remove. They're encrypted.
> >You could blank them like the log files.
> >
> >The key pairs themselves only have visible hostnames in the public
> >part's file.
> 
> Ah, yes!  Thanks.  Some brain cells knew that, but were sleeping.
> But actually I want to keep that ~/.ssh/known_hosts so I can ssh
> from this new RPi to the other machines on my LAN without having to
> reconfigure all that ssh stuff... one of the several time-saving
> reasons I'm (quasi-)duplicating the SD card.
> 
> But you bring up a very good point: I don't want the new system to
> have the same /etc/ssh/ssh_host_*key* files that the previous system
> has.  Though it might work okay, still I think the sshd host keys
> are meant to be unique across all LAN'd systems (ideally unique in
> the universe).  So I think I need to do "rm etc/ssh/ssh_host_*key*"
> so that sshd knows they're gone; in the past IIRC these host keys
> were automatically created, probably done in the sshd script under
> init.d;  I hope that it's the same under the new-fangled systemd
> code.

After removing the old (duplicate) keys, just do
# ssh-keygen -A
to generate a new set. Then restart the ssh server with
# /etc/init.d/ssh restart
so it reads and uses the new keys.

> >>Since people are supposed to be able (I think, never done) to take
> >>an SD out of one RPi and put and boot it in another RPi (with the
> >>same hardware), I didn't make any attempt to find and change any
> >>hardware designations, like the MAC address of the NIC.  Is that
> >>okay?
> >>
> >>Your router may know IP#/MAC combinations for dhcp.
> 
> I'm not using dhcpd on the router, so that won't affect me. But for
> those who do, if you can do "arp -a" on your router, that will show
> which MAC addresses are cached; "arp -d address" will delete that
> address's entry in the arp table, allowing/obligating the system to
> generate a/the new entry.

I wasn't meaning MACs _cached_ in the router, but MACs _configured_
there, so that its dhcp server gives the correct (fixed) IP# to each
host according to its MAC. Thus my laptop's IP# was 10.x.x.x this
morning at the airport (issued by their dhcp server) but it switched
to the same old 192.168.1.y when I got home because it has an address
reserved for it.

(That's for others' benefit.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#166644 — Re: [Raspbian-devel] change hostname & static IP & ???

[Multipart message — attachments visible in raw view] — view raw

The SD cards can in general be swapped around Raspberry PI cards.

The MAC address is stored in the network adapter on the Raspberry PI, so
unless you change it, each raspberry PI will have a uniqe MAC address.

Default IP configuration is to use DHCP. This usually causes the the
address to follow the raspberry PI card, since the router will remember
which IP address it used to have, unless the card has been offline for some
time. Some routers forgets this information on reboot. If the router does
not have old information about the MAC address from the client, it can use
the hint sent from the client before deciding which address it shall have.
The client usually hints about which IP address it had last time it was
connected. When moving SD cards between raspberry PI cards, this hint will
follow the SD card, since it is stored in a file.


If you configure the IP address to be static, then the address will follow
the SD card, since that is where you store that information:
https://wiki.debian.org/NetworkConfiguration#Configuring_the_interface_manually

Stian

On Tue, Apr 12, 2016 at 1:02 AM, ken <gebser@mousecar.com> wrote:

> This is on Wheezy for a Raspberry Pi.
>
> Using dd, I copied the SD card for one (nicely working and configured)
> system onto another SD card.  I want to use this second card for another
> system, so need to change the hostname and (static) IP address.  Yesterday
> I grepped the whole system for one and then the other and where I found
> either, I made appropriate changes (i.e., previous hostname to new
> hostname, previous IP address to new IP address).  I also zeroed out all
> text-based files in /var/log/ (e.g., >messages), just to start the new
> system with clean logs.
>
> Both the previous (still running) system and the new one (not yet running)
> are to be on the same LAN, so I'm pretty certain that no other networking
> configuration-- like broadcast or netmask-- needs to be touched (how could
> it need any?).
>
> Neither of these systems has any public-facing services currently running.
>
> My concerns are these:
>
> Only files which grep could find were amended. (Note that grep was run on
> the card when it was mounted on another system, not when the system on that
> card was booted and running.)  Is there a file of some kind, perhaps, which
> encodes either the hostname and/or IP address in such a way that would hide
> it/them from grep?
>
> Since people are supposed to be able (I think, never done) to take an SD
> out of one RPi and put and boot it in another RPi (with the same hardware),
> I didn't make any attempt to find and change any hardware designations,
> like the MAC address of the NIC.  Is that okay?
>
> Is there anything I'm missing or forgetting?
>
>
> tia for fullohelp tips.
>

-- 
Stian Skjelstad
Barnfind Technologies

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web