Discuss February 2013

discuss@lists.centos.org

203 participants
197 discussions

apcupsd, odd behavior
by m.roth＠5-cent.us 16 Feb '13

16 Feb '13

As we have every day, we had a power blip overnight. one, at least, of the servers connected to a SmartUPS via cable, announced that "power exhausted, initiating shutdown" (which I've disabled). The thing is, I know the servers on that UPS draw a ridiculous amount of power, but I don't see that on the others... and this was three seconds, not minutes, after it announced there was a power outage. Has anyone else seen this behavior? mark

7 15

OT: UPS battery vendor, cont'd
by m.roth＠5-cent.us 16 Feb '13

16 Feb '13

Here's the state of my search: BatteriesPlus is... odd. The corporate site, and after a phone call, tell me they don't do GSA, but some of their franchises do. I called the local one, and they do. However, the only RBC 43 they offer, I might as well buy direct from APC, at well over $300 for the set. Battery Sharks, and Apex, don't do GSA... but they *do* offer replacements for about $100 for the set. Having checked with my manager, we'll try the open market quotes. I would like a third recommendation, so I can offer purchasing three quotes. Recommendations? And thanks to all. mark

10 17

Really changing the hostname
by Robert Moskowitz 16 Feb '13

16 Feb '13

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.

9 26

Re: [CentOS] More on Re: Really changing the hostname
by Les Mikesell 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 5:10 PM, Reindl Harald <h.reindl(a)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(a)gmail.com

1 0

Re: [CentOS] More on Re: Really changing the hostname
by Les Mikesell 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 4:36 PM, Reindl Harald <h.reindl(a)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 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 doing Sure, 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(a)gmail.com

1 0

Re: [CentOS] More on Re: Really changing the hostname
by Les Mikesell 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 4:26 PM, Reindl Harald <h.reindl(a)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 files I 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(a)gmail.com

1 0

Re: [CentOS] More on Re: Really changing the hostname
by Les Mikesell 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 3:52 PM, Reindl Harald <h.reindl(a)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 MAC Most 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(a)gmail.com

1 0

Re: [CentOS] More on Re: Really changing the hostname
by Les Mikesell 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 3:14 PM, Reindl Harald <h.reindl(a)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 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? >> 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. -- Les Mikesell lesmikesell(a)gmail.com

1 0

Re: [CentOS] More on Re: Really changing the hostname
by Les Mikesell 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 2:55 PM, Reindl Harald <h.reindl(a)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(a)gmail.com

1 0

Re: [CentOS] More on Re: Really changing the hostname
by Les Mikesell 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 2:34 PM, Reindl Harald <h.reindl(a)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 > needed 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. >> 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. -- Les Mikesell lesmikesell(a)gmail.com

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss February 2013