I need to change the host name on a test server, and in the past when I used hostname to change the hostname, it did not seem to change it everywhere. I really don't want to do a rebuild just yet, but I have to feel confident that hostname is really changed (reboot is not too much of an issue). What is the recommened practice? Other than get it right the first time.
On 02/14/2013 01:11 PM, Robert Moskowitz wrote:> I need to change the host name on a test server, and in the past when I > used hostname to change the hostname, it did not seem to change it > everywhere. > > I really don't want to do a rebuild just yet, but I have to feel > confident that hostname is really changed (reboot is not too much of an > issue). > > What is the recommened practice? Other than get it right the first time.To make the change permanent, edit /etc/ssyconfig/network and set the desired hostname after HOSTNAME=. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Les Mikesell wrote:> On Thu, Feb 14, 2013 at 12:15 PM, Digimer <lists at alteeve.ca> wrote: >> On 02/14/2013 01:13 PM, Digimer wrote: >>> On 02/14/2013 01:11 PM, Robert Moskowitz wrote: >>>> I need to change the host name on a test server, and in the past whenI used hostname to change the hostname, it did not seem to change it everywhere.>>>> >>>> I really don't want to do a rebuild just yet, but I have to feelconfident that hostname is really changed (reboot is not too much of an issue).>>>> >>>> What is the recommened practice? Other than get it right the firsttime.>>> >>> To make the change permanent, edit /etc/ssyconfig/network and set thedesired hostname after HOSTNAME=.>> >> Sorry, I typo'd that; >> >> # cat /etc/sysconfig/network >> NETWORKING=yes >> HOSTNAME=<your.new.hostname> > > This will get picked up on the next reboot. You will have to use thehostname command to make it take effect immediately, but some> applications only pick it up when they start so things like your loginprompt won't change until the next login. Yep, what les says. If you don't reboot, things like syslog/rsyslog won't change it in messages. mark
Thanks all. Changed /etc/sysconfig/network and rebooted and all is well. At least so far! /etc/hosts did not have an entry for the host there. Maybe because I have installed bind on this system. On 02/14/2013 01:11 PM, Robert Moskowitz wrote:> I need to change the host name on a test server, and in the past when I > used hostname to change the hostname, it did not seem to change it > everywhere. > > I really don't want to do a rebuild just yet, but I have to feel > confident that hostname is really changed (reboot is not too much of an > issue). > > What is the recommened practice? Other than get it right the first time. > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >
On 02/15/2013 02:02 PM, Reindl Harald wrote:> > Am 15.02.2013 19:58, schrieb Les Mikesell: >> On Fri, Feb 15, 2013 at 12:49 PM, Reindl Harald <h.reindl at thelounge.net> wrote: >>>>> And when you edit ifcfg-eth0 what command restarts the interface? >>>> ifdown eth0 >>>> ifup eth0 >>> oh yeah do this in a ssh session >>> man "service network restart" works and does not lock you out >> ifdown eth0 ; ifup eth0 >> ...works for me. But most of our machines have multiple interfaces >> so I'll usually connect to a different one > ah and all your interfaces are connected to the WAN? > why? > >> while I change a NIC >> setting - and the most common thing would be to change the IP address >> anyway > ah and that is why you suggest > > service NetworkManger stop > chkconfig NetworkManager off > > to somebody which locks him out and even after a cold reboot > comes up without network because you missed "chkconfig network > on" - but not relevant, there would have been no connection to type > it after shutdown NMI just checked this on my new server running network with how it comes 'out of the box'. chkconfig --list shows both NetworkManager and network as on right now. I suppose to future proof myself it would be wise to still run "chkconfig network on"; it hurts nothing if on and could save me if a future release is shipped defaulted off. hmmm. I did set network on in my kickstart to do a netinstall; maybe that is why network is on now? Doesn't matter, I suppose.
On Fri, Feb 15, 2013 at 2:24 PM, Reindl Harald <h.reindl at thelounge.net> wrote:> > well, that is why you should remove any reference to the MAC address > from "ifcfg-eth*" to have "70-persistent-net.rules" as single instance > for this assignmentOr make them match. In either case I am somewhat nervous about depending on files that sometimes magically get re-written - and don't really understand the things that can trigger it. -- Les Mikesell lesmikesell at gmail.com
On Fri, Feb 15, 2013 at 2:34 PM, Reindl Harald <h.reindl at thelounge.net> wrote:> >>> well, that is why you should remove any reference to the MAC address >>> from "ifcfg-eth*" to have "70-persistent-net.rules" as single instance >>> for this assignment >> >> Or make them match > > why would someone want the need to edit two config > files with the same value if the name of the interface > is what counts? > > after you have prepared a migration to a virtual infrastructure > and because other reasons the MAC was changed and your whole > "sync data, shutdown interface on old machine and start on the > new one" failed because this fucking entry in "ifcfg-eth*" you > will never ever enter in this file ANYTHING which is not hardly > neededYou still have to deal with at least one file, and if you can fix one it's not that much harder to fix two. Almost all of our machines (virtual and real) have multiple interfaces.>> In either case I am somewhat nervous about >> depending on files that sometimes magically get re-written - and don't >> really understand the things that can trigger it > > call your interfaces in "70-persistent-net.rules" "lan0", "lan1", > "wan0" and change "ifcfg-eth*" to match and this will not happenIf the system re-writes 70-persistent-net.rules itself, the names will change and the NIC ordering is unpredictable. And if you script a fixup, it's just another line or two to fix the matching ifcfg-* files. -- Les Mikesell lesmikesell at gmail.com
On Fri, Feb 15, 2013 at 2:55 PM, Reindl Harald <h.reindl at thelounge.net> wrote:> >> You still have to deal with at least one file, and if you can fix one >> it's not that much harder to fix two. Almost all of our machines >> (virtual and real) have multiple interfaces. > > so what - why should i edit 2 files if one is enough > >>>> In either case I am somewhat nervous about >>>> depending on files that sometimes magically get re-written - and don't >>>> really understand the things that can trigger it >>> >>> call your interfaces in "70-persistent-net.rules" "lan0", "lan1", >>> "wan0" and change "ifcfg-eth*" to match and this will not happen >> >> If the system re-writes 70-persistent-net.rules itself, the names will >> change and the NIC ordering is unpredictable. And if you script a >> fixup, it's just another line or two to fix the matching ifcfg-* >> files > > you do not understand what i have said > > the race between kernel enumeration and udev is the reason > why it is unpredictable, do not use the kernel names on machines > with more than one interfaces and NOTHING will fuckup your > "lan0", "lan1"....I don't understand how you create that udev entry before you need it. Or why one udev-assigned name is different from any other name once it is in place in that file. -- Les Mikesell lesmikesell at gmail.com
On Fri, Feb 15, 2013 at 3:14 PM, Reindl Harald <h.reindl at thelounge.net> wrote:> >>> you do not understand what i have said >>> >>> the race between kernel enumeration and udev is the reason >>> why it is unpredictable, do not use the kernel names on machines >>> with more than one interfaces and NOTHING will fuckup your >>> "lan0", "lan1".... >> >> I don't understand how you create that udev entry before you need it > > easy if you know the MAC addressDo you mean you make the change in a virtual system image before copying/changing the virtual MACs? Or in a script that runs during boot up before the network comes up?>> Or why one udev-assigned name is different from any other name once >> it is in place in that file > > you know what race-condition means? > https://bugzilla.redhat.com/show_bug.cgi?id=782145I suppose that's possible, but doesn't have much to do with the issue of making the ifcfg-* files match the MAC address. -- Les Mikesell lesmikesell at gmail.com
On Fri, Feb 15, 2013 at 3:52 PM, Reindl Harald <h.reindl at thelounge.net> wrote:> >>>> I don't understand how you create that udev entry before you need it >>> >>> easy if you know the MAC address >> >> Do you mean you make the change in a virtual system image before >> copying/changing the virtual MACs? Or in a script that runs during >> boot up before the network comes up? > > before changing the MACMost of our machines are physical and the issue happens when I swap disks to a new chassis or clone images. The same solution 'could' work, but I generally don't know ahead of time where the image is going.>>>> Or why one udev-assigned name is different from any other name once >>>> it is in place in that file >>> >>> you know what race-condition means? >>> https://bugzilla.redhat.com/show_bug.cgi?id=782145 >> >> I suppose that's possible, but doesn't have much to do with the issue >> of making the ifcfg-* files match the MAC address. > > WTF - this issue does not exist if you are not so stupid > and place the MAC address additionally to the udev-rule > in the ifcfg-*No, the link you posted has to do with a race between the kernel itself and udev. Nothing to do with what happens at ifup time. Things would already be broken by then, though. I do see how not using the same names the kernel would auto-assign would avoid the race problem, but I'm not sure it happens in CentOS. If you use fedora, you deserve the extra bugs. -- Les Mikesell lesmikesell at gmail.com
On Fri, Feb 15, 2013 at 4:26 PM, Reindl Harald <h.reindl at thelounge.net> wrote:> > and explain someone that it does not matter if you have to edit one > or two files is plain stupid - why do you not put the MAC in 50 > config files, well no need for it, but if you have fun do it, there > is also no need for do it in two filesI didn't invent the system, and was perfectly happy when the MAC matching was broken in early 5.x. But if you want it to be change, why not complain upstream where a change is possible. As things are, you have to edit the ifcfg-? files anyway and it's not that big a deal to put what the system expects in there. In fact I usually start with the copy that already has the right MAC and add everything else. -- Les Mikesell lesmikesell at gmail.com
On Fri, Feb 15, 2013 at 4:36 PM, Reindl Harald <h.reindl at thelounge.net> wrote:> > dmaned - it is enough to enter the MAC at one place > it does not matter that you have to look at udev and ifcfg > the point is you do NOT need to put the MAC in bothAnd my point is that once the machine has booted and created the udev rule file, it will also have created matching MAC entries in the ifcfg-* files. It is as much work to remove them as to use them as the starting point when adding the rest of the settings. Except maybe in your unusual case of knowing a running system is going to be moved/cloned to known new MACs.> i said nothing more and nothing less if you go back in > the thread and if you do not understand this be happy > with write MAC addresses twice at every change, i keep > on doing no useless copy of config-settings and that > i made some undret dist-upgrades in a few years without > production shows that i am right and know what i am doingSure, but there is always more than one way to do things. And like the people who sell investments are fond of saying, "past performance is no guarantee of future results". -- Les Mikesell lesmikesell at gmail.com
On Fri, Feb 15, 2013 at 5:10 PM, Reindl Harald <h.reindl at thelounge.net> wrote:> >>> dmaned - it is enough to enter the MAC at one place >>> it does not matter that you have to look at udev and ifcfg >>> the point is you do NOT need to put the MAC in both >> >> And my point is that once the machine has booted and created the udev >> rule file, it will also have created matching MAC entries in the >> ifcfg-* files. It is as much work to remove them > > uhm why they are existing at all? > do you create your ifcfg-files with GUI crap?No, it is anaconda or kudzu magic that happens before you would get to a GUI even if you used one. Delete your copies on a box where you have console access (or at least dchp) and see what you get after a reboot.> there where i work they do not exist since years > and new machines are not installed from zero, they > are cloned with existing configs and symlinks to > the udev-rules in /root/If the files exist and MACs are correct they normally don't change - but I'm not quite sure what triggers kudzu to change things. -- Les Mikesell lesmikesell at gmail.com