Re: manually fixing IPs
On Fri, 2011-04-01 at 05:20 +0200, Ralf Corsepius wrote: > On 03/31/2011 07:28 PM, Dan Williams wrote: > > On Sun, 2011-03-27 at 17:57 +0200, Ralf Corsepius wrote: > >> On 03/27/2011 05:27 PM, Chuck Anderson wrote: > >>> On Sun, Mar 27, 2011 at 03:58:06PM +0200, Ralf Ertzinger wrote: > Hi. > > On Sun, 27 Mar 2011 15:48:14 +0200, Kevin Kofler wrote > > NM supports static IPs these days. So I think that rather than > > hacking around NM, you should just fix the IP inside NM's > > configuration and have NM work FOR you rather than AGAINST you. > > I'm sorry, but by the time I have clicked through the GUI to do > that I have configured the interface via ip, did what I wanted to > do and unconfigured the interface again. > > I uncheck "Enable networking" in nm-applet before doing that, > and for me that makes NM keep it's grubby paws off my manually > configured interface, so I'm not complaining. > >>> > >>> You don't need to use the GUI. Just edit > >>> /etc/sysconfig/network-scripts/ifcfg-* with a static IP and NM will > >>> pick it up right away and configure it. > >> > >> And how to tweak /etc/sysconfig/network-scripts/ifcfg-* (and/or > >> /etc/sysconfig/network) for static IPs such that NM sets > >> hostname/domainname correctly? > > > Let me try to provide more details: > > Given a small (3 machines), wired (No WLAN, no VPN), static network > without dhcp and static IPs only, on a subnet of a larger network > (provides DNS), which is supposed to appear on a (private) domain of its > own (It's a lab's network). > > When adding a Fedora machine, > * with the "network" scripts it was possibile to assign the domainname > through /etc/sysconfig/network. > - "hostname" returned "", > - "hostname -f" returned "." man hostname: The function gethostname(2) is used to get the hostname. When the hostname -a, -d, -f or -i is called will gethostbyname(3) be called. The difference in gethostname(2) and gethostbyname(3) is that gethost‐ byname(3) is network aware, so it consults /etc/nsswitch.conf and /etc/host.conf to decide whether to read information in /etc/syscon‐ fig/network or /etc/hosts So here's what you do. Set your hostname to "happy" by modifying /etc/sysconfig/network: HOSTNAME=happy and update your /etc/hosts file to include this line: 127.0.0.1 happy.foobar.com happy localhost.localdomain localhost Then, 'hostname' will return "happy", and "hostname -f" will return happy.foobar.com as you desire. But note that 'man hostname' also says: It is not possible to set the FQDN or the DNS domain name with the dns‐ domainname command (see THE FQDN below). and further: You can't change the FQDN (as returned by hostname --fqdn) or the DNS domain name (as returned by dnsdomainname) with this command. The FQDN of the system is the name that the resolver(3) returns for the host name. Technically: The FQDN is the name getaddrinfo(3) returns for the host name returned by gethostname(2). The DNS domain name is the part after the first dot. Therefore it depends on the configuration (usually in /etc/host.conf) how you can change it. Usually (if the hosts file is parsed before DNS or NIS) you can change it in /etc/hosts. If a machine has multiple network interfaces/addresses or is used in a mobile environment, then it may either have multiple FQDNs/domain names or none at all. Therefore avoid using hostname --fqdn, hostname --domain and dnsdomainname. hostname --ip-address is subject to the same limitations so it should be avoided as well. So basically, if you don't have control over your DNS setup, you can't control your FQDN (obviously). If you have a small network, you probably *do* want to set your machine hostname to the FQDN if you for any reason need FQDNs at all. Otherwise you get to keep /etc/hosts up to date between all machines. Dan > * with NM, when > - using a fqn as hostname in > /etc/sysconf/networking-scripts/ifcfg*eth0 (rsp. nm-connection-editor), > both "hostname" and "hostname -f" always return the FQDN: > "." > - using "" as hostname in > /etc/sysconf/networking-scripts/ifcfg*eth0 rsp. nm-connection-editor, > "hostname" returns " sometimes returned "", sometimes an empty string, sometimes > "localhost" and sometimes even hung. > > I don't know the exact causes. We've tried various things, but never > could make NM working as desired. > > In other words, my question is: > How to configure NM in a private, dhcp-less, static network, with only > static IPs, such that > "hostname" returns "" and > "hostname -f" returns "." > > > domainname is only used for NIS, > Hmm, this doesn't match with my understanding. Domainname and > ypdomainname are separate things. Domainname is the "domain part" of a > "FQDN",
Re: manually fixing IPs
Ralf Corsepius wrote: > In other words, my question is: > How to configure NM in a private, dhcp-less, static network, with only > static IPs, such that > "hostname" returns "" and > "hostname -f" returns "." I take it you have compelling reasons to avoid "hostname --short"? Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Fri, Apr 01, 2011 at 05:20:03AM +0200, Ralf Corsepius wrote: > On 03/31/2011 07:28 PM, Dan Williams wrote: > > > domainname is only used for NIS, > Hmm, this doesn't match with my understanding. Domainname and > ypdomainname are separate things. Domainname is the "domain part" of a > "FQDN", while ypdomainname is complete independent from the domainname > and may be set to something entirely different than "domainname". Actually, domainname and ypdomainname appear to be the same things: HOSTNAME(1)Linux Programmer’s Manual HOSTNAME(1) NAME hostname - show or set the system’s host name domainname - show or set the system’s NIS/YP domain name dnsdomainname - show the system’s DNS domain name nisdomainname - show or set system’s NIS/YP domain name ypdomainname - show or set the system’s NIS/YP domain name ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On 03/31/2011 07:28 PM, Dan Williams wrote: > On Sun, 2011-03-27 at 17:57 +0200, Ralf Corsepius wrote: >> On 03/27/2011 05:27 PM, Chuck Anderson wrote: >>> On Sun, Mar 27, 2011 at 03:58:06PM +0200, Ralf Ertzinger wrote: Hi. On Sun, 27 Mar 2011 15:48:14 +0200, Kevin Kofler wrote > NM supports static IPs these days. So I think that rather than > hacking around NM, you should just fix the IP inside NM's > configuration and have NM work FOR you rather than AGAINST you. I'm sorry, but by the time I have clicked through the GUI to do that I have configured the interface via ip, did what I wanted to do and unconfigured the interface again. I uncheck "Enable networking" in nm-applet before doing that, and for me that makes NM keep it's grubby paws off my manually configured interface, so I'm not complaining. >>> >>> You don't need to use the GUI. Just edit >>> /etc/sysconfig/network-scripts/ifcfg-* with a static IP and NM will >>> pick it up right away and configure it. >> >> And how to tweak /etc/sysconfig/network-scripts/ifcfg-* (and/or >> /etc/sysconfig/network) for static IPs such that NM sets >> hostname/domainname correctly? > Let me try to provide more details: Given a small (3 machines), wired (No WLAN, no VPN), static network without dhcp and static IPs only, on a subnet of a larger network (provides DNS), which is supposed to appear on a (private) domain of its own (It's a lab's network). When adding a Fedora machine, * with the "network" scripts it was possibile to assign the domainname through /etc/sysconfig/network. - "hostname" returned "", - "hostname -f" returned "." * with NM, when - using a fqn as hostname in /etc/sysconf/networking-scripts/ifcfg*eth0 (rsp. nm-connection-editor), both "hostname" and "hostname -f" always return the FQDN: "." - using "" as hostname in /etc/sysconf/networking-scripts/ifcfg*eth0 rsp. nm-connection-editor, "hostname" returns "", sometimes an empty string, sometimes "localhost" and sometimes even hung. I don't know the exact causes. We've tried various things, but never could make NM working as desired. In other words, my question is: How to configure NM in a private, dhcp-less, static network, with only static IPs, such that "hostname" returns "" and "hostname -f" returns "." > domainname is only used for NIS, Hmm, this doesn't match with my understanding. Domainname and ypdomainname are separate things. Domainname is the "domain part" of a "FQDN", while ypdomainname is complete independent from the domainname and may be set to something entirely different than "domainname". > which I assume you're not running. We are using yp/NIS for this private network, but currently are not using it for hostname resolution. > Otherwise, if you have a persistent hostname set > in /etc/sysconfig/network (HOSTNAME=adasdasdf) then NM will respect > that. If you do not have a persistent hostname set, then the hostname > will come from the DHCP server, or if not available from DHCP, from > reverse DNS lookup of your IP address, just as with the 'network' > service. > NM will update your /etc/resolv.conf with various domains taken from > your hostname, so if your hostname is "blah.foobar.com", NM will add > "foobar.com" to the searches in /etc/resolv.conf. > > As has been stated before, NM does not touch /etc/hosts anymore. Could you tell me since when? The machines in question are running F13 ( Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sun, 2011-03-27 at 17:57 +0200, Ralf Corsepius wrote: > On 03/27/2011 05:27 PM, Chuck Anderson wrote: > > On Sun, Mar 27, 2011 at 03:58:06PM +0200, Ralf Ertzinger wrote: > >> Hi. > >> > >> On Sun, 27 Mar 2011 15:48:14 +0200, Kevin Kofler wrote > >>> NM supports static IPs these days. So I think that rather than > >>> hacking around NM, you should just fix the IP inside NM's > >>> configuration and have NM work FOR you rather than AGAINST you. > >> > >> I'm sorry, but by the time I have clicked through the GUI to do > >> that I have configured the interface via ip, did what I wanted to > >> do and unconfigured the interface again. > >> > >> I uncheck "Enable networking" in nm-applet before doing that, > >> and for me that makes NM keep it's grubby paws off my manually > >> configured interface, so I'm not complaining. > > > > You don't need to use the GUI. Just edit > > /etc/sysconfig/network-scripts/ifcfg-* with a static IP and NM will > > pick it up right away and configure it. > > And how to tweak /etc/sysconfig/network-scripts/ifcfg-* (and/or > /etc/sysconfig/network) for static IPs such that NM sets > hostname/domainname correctly? domainname is only used for NIS, which I assume you're not running. Otherwise, if you have a persistent hostname set in /etc/sysconfig/network (HOSTNAME=adasdasdf) then NM will respect that. If you do not have a persistent hostname set, then the hostname will come from the DHCP server, or if not available from DHCP, from reverse DNS lookup of your IP address, just as with the 'network' service. NM will update your /etc/resolv.conf with various domains taken from your hostname, so if your hostname is "blah.foobar.com", NM will add "foobar.com" to the searches in /etc/resolv.conf. As has been stated before, NM does not touch /etc/hosts anymore. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bluetooth service - was manually fixing IPs
Michal Schmidt (mschm...@redhat.com) said: > Compare this with org.freedesktop.NetworkManager.service which uses an > indirect alias that can be enabled/disabled by systemctl: > SystemdService=dbus-org.freedesktop.NetworkManager.service > > This was discussed in February on systemd-devel: > http://lists.freedesktop.org/archives/systemd-devel/2011-February/001384.html Note that this doesn't appear to be working right, or at least isn't implemented in NM the way an admin would expect: https://bugzilla.redhat.com/show_bug.cgi?id=691549 Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bluetooth service - was manually fixing IPs
On Tue, 29 Mar 2011 17:34:39 -0500 Ian Pilcher wrote: > On 03/29/2011 03:01 PM, Lennart Poettering wrote: > > Can you paste the kmsg context of the starting please? > > [ 42.087581] systemd[1]: Got D-Bus activation request for > bluetooth.service The bluez D-Bus service activates bluetooth.service directly. See /usr/share/dbus-1/system-services/org.bluez.service: ... SystemdService=bluetooth.service Compare this with org.freedesktop.NetworkManager.service which uses an indirect alias that can be enabled/disabled by systemctl: SystemdService=dbus-org.freedesktop.NetworkManager.service This was discussed in February on systemd-devel: http://lists.freedesktop.org/archives/systemd-devel/2011-February/001384.html Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bluetooth service - was manually fixing IPs
On 03/29/2011 03:01 PM, Lennart Poettering wrote: > Can you paste the kmsg context of the starting please? [ 42.087581] systemd[1]: Got D-Bus activation request for bluetooth.service [ 42.099029] systemd[1]: Trying to enqueue job bluetooth.service/start/replace [ 42.099342] systemd[1]: Installed new job bluetooth.service/start as 382 [ 42.099351] systemd[1]: Enqueued job bluetooth.service/start as 382 [ 42.099407] systemd[1]: About to execute: /usr/sbin/bluetoothd -n [ 42.112528] systemd[1]: Forked /usr/sbin/bluetoothd as 2103 [ 42.112627] systemd[1]: bluetooth.service changed dead -> start [ 42.168637] bluetoothd[2103]: bluetoothd[2103]: Bluetooth deamon 4.87 [ 42.183808] systemd[1]: Got D-Bus request: org.freedesktop.DBus.NameOwnerChanged() on /org/freedesktop/DBus [ 42.184485] systemd[1]: Got D-Bus request: org.freedesktop.DBus.NameOwnerChanged() on /org/freedesktop/DBusbluetoothd[2103]: bluetoothd[2103]: Starting SDP server [ 42.184491] [ 42.184496] systemd[1]: bluetooth.service's D-Bus name org.bluez now registered by :1.23 [ 42.184528] systemd[1]: bluetooth.service changed start -> running [ 42.184536] systemd[1]: Job bluetooth.service/start finished, result=done So it looks like it is being started via D-BUS, even though the service is disabled. (I just re-re-re-verified that.) -- Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bluetooth service - was manually fixing IPs
On Tue, 29.03.11 14:54, Ian Pilcher (arequip...@gmail.com) wrote: > > On 03/29/2011 02:44 PM, Lennart Poettering wrote: > > Maybe something started it manually? > > Looks like it happens when I log in to KDE. > > I assume this means that KDE isn't using D-BUS to start the service, > right? If it were, disabling it with systemctl would have worked. I have no idea what KDE does. If it really manually runs "systemctl start bluetooth.service" (or "/sbin/service bluetooth start") then the KDE folks should stop doing that. They should respect system configuration, and not manually start something the admin explicitly didn't want to get started. Can you paste the kmsg context of the starting please? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bluetooth service - was manually fixing IPs
On 03/29/2011 02:44 PM, Lennart Poettering wrote: > Maybe something started it manually? Looks like it happens when I log in to KDE. I assume this means that KDE isn't using D-BUS to start the service, right? If it were, disabling it with systemctl would have worked. Thanks! -- Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bluetooth service - was manually fixing IPs
On Tue, 29.03.11 14:39, Ian Pilcher (arequip...@gmail.com) wrote: > On 03/29/2011 02:31 PM, Lennart Poettering wrote: > > Please paste "systemctl show bluetooth.service", which should tell us > > what pulled it in. > > Here it is. > > Id=bluetooth.service > Names=bluetooth.service > Requires=systemd-logger.socket dbus.target basic.target > Conflicts=shutdown.target > Before=shutdown.target > After=syslog.target systemd-logger.socket dbus.target basic.target It's not pulled in by anything at all according to this, so the disabling worked. Maybe something started it manually? Try to boot with "systemd.log_level=debug systemd.log_target=kmsg log_buf_len=2M" on the kernel cmdline. Then keep an eye on dmesg, look for "bluetooth.service" being mentioned. If you find something, tell me and paste those lines and the context around it and I might be able to tell you what activated it. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bluetooth service - was manually fixing IPs
On 03/29/2011 02:31 PM, Lennart Poettering wrote:
> Please paste "systemctl show bluetooth.service", which should tell us
> what pulled it in.
Here it is.
Id=bluetooth.service
Names=bluetooth.service
Requires=systemd-logger.socket dbus.target basic.target
Conflicts=shutdown.target
Before=shutdown.target
After=syslog.target systemd-logger.socket dbus.target basic.target
Description=Bluetooth Manager
LoadState=loaded
ActiveState=active
SubState=running
FragmentPath=/lib/systemd/system/bluetooth.service
InactiveExitTimestamp=Tue, 29 Mar 2011 09:16:39 -0500
ActiveEnterTimestamp=Tue, 29 Mar 2011 09:16:39 -0500
CanStart=yes
CanStop=yes
CanReload=no
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
DefaultControlGroup=name=systemd:/system/bluetooth.service
ControlGroup=cpu:/system/bluetooth.service
name=systemd:/system/bluetooth.service
NeedDaemonReload=no
JobTimeoutUSec=0
Type=dbus
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutUSec=3min
ExecStart={ path=/usr/sbin/bluetoothd ; argv[]=/usr/sbin/bluetoothd -n ;
ignore=no ; start_time=[Tue, 29 Mar 2011 09:16:39 -0500] ; stop_time=[n/a
UMask=0002
LimitCPU=18446744073709551615
LimitFSIZE=18446744073709551615
LimitDATA=18446744073709551615
LimitSTACK=18446744073709551615
LimitCORE=18446744073709551615
LimitRSS=18446744073709551615
LimitNOFILE=1024
LimitAS=18446744073709551615
LimitNPROC=59941
LimitMEMLOCK=65536
LimitLOCKS=18446744073709551615
LimitSIGPENDING=59941
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=5
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=syslog
StandardError=inherit
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSetDrop=0
MountFlags=1048576
PrivateTmp=no
SameProcessGroup=no
KillMode=control-group
KillSignal=15
PermissionsStartOnly=no
RootDirectoryStartOnly=no
RemainAfterExit=no
GuessMainPID=yes
ExecMainStartTimestamp=Tue, 29 Mar 2011 09:16:39 -0500
ExecMainExitTimestamp=Tue, 29 Mar 2011 09:16:39 -0500
ExecMainPID=2140
ExecMainCode=0
ExecMainStatus=0
MainPID=2140
ControlPID=0
BusName=org.bluez
SysVStartPriority=-1
FsckPassNo=0
--
Ian Pilcher arequip...@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Tue, 29.03.11 14:23, Ian Pilcher (arequip...@gmail.com) wrote: > On 03/29/2011 12:14 PM, Lennart Poettering wrote: > > http://0pointer.de/blog/projects/three-levels-of-off > > Any ideas why this is happening? > > [pilcher@ian ~]$ systemctl is-enabled bluetooth.service && echo ENABLED > [pilcher@ian ~]$ systemctl status bluetooth.service > bluetooth.service - Bluetooth Manager > Loaded: loaded (/lib/systemd/system/bluetooth.service) > Active: active (running) since Tue, 29 Mar 2011 09:16:39 > -0500; 5h 4min ago > Main PID: 2140 (bluetoothd) > CGroup: name=systemd:/system/bluetooth.service > └ 2140 /usr/sbin/bluetoothd -n > > (And, yes, I've rebooted many times since disabling it.) Please paste "systemctl show bluetooth.service", which should tell us what pulled it in. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On 03/29/2011 12:14 PM, Lennart Poettering wrote: > http://0pointer.de/blog/projects/three-levels-of-off Any ideas why this is happening? [pilcher@ian ~]$ systemctl is-enabled bluetooth.service && echo ENABLED [pilcher@ian ~]$ systemctl status bluetooth.service bluetooth.service - Bluetooth Manager Loaded: loaded (/lib/systemd/system/bluetooth.service) Active: active (running) since Tue, 29 Mar 2011 09:16:39 -0500; 5h 4min ago Main PID: 2140 (bluetoothd) CGroup: name=systemd:/system/bluetooth.service └ 2140 /usr/sbin/bluetoothd -n (And, yes, I've rebooted many times since disabling it.) -- Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Tue, 29.03.11 10:12, Adam Williamson (awill...@redhat.com) wrote: > > On Tue, 2011-03-29 at 02:35 -0400, Jon Masters wrote: > > > For clarification, I usually do have NM_CONTROLLED set for every > > interface, except on laptops. In this case, I just wanted to instead > > turn off NetworkManager and configure the interface manually. I see no > > reason why it shouldn't be possible to tell a system service to stop and > > expect it to stay stopped until I turn it back on again. That way, I can > > tell NM to shutdown, do something I need to do, then get the prettified > > laptop experience back again when I'm done (on the netbook). > > > > This was all to tftp various firmwares over to routers I was playing > > with over the weekend. Soldering surface mount bits, placing wires, and > > poking at serial consoles and firmware setup was trivial. The hardest > > bit was telling a system service to stay stopped :) > > If just stopping it with 'systemctl stop NetworkManager.service' didn't > do the job, I would imagine you were running up against systemd's bus > activation feature; when something tried to poke NM via dbus, systemd > would fire it up. Lennart may be able to suggest how you can avoid this, > if it's possible. http://0pointer.de/blog/projects/three-levels-of-off Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Tue, 2011-03-29 at 02:35 -0400, Jon Masters wrote: > For clarification, I usually do have NM_CONTROLLED set for every > interface, except on laptops. In this case, I just wanted to instead > turn off NetworkManager and configure the interface manually. I see no > reason why it shouldn't be possible to tell a system service to stop and > expect it to stay stopped until I turn it back on again. That way, I can > tell NM to shutdown, do something I need to do, then get the prettified > laptop experience back again when I'm done (on the netbook). > > This was all to tftp various firmwares over to routers I was playing > with over the weekend. Soldering surface mount bits, placing wires, and > poking at serial consoles and firmware setup was trivial. The hardest > bit was telling a system service to stay stopped :) If just stopping it with 'systemctl stop NetworkManager.service' didn't do the job, I would imagine you were running up against systemd's bus activation feature; when something tried to poke NM via dbus, systemd would fire it up. Lennart may be able to suggest how you can avoid this, if it's possible. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Mon, 2011-03-28 at 14:47 -0400, Jeff Garzik wrote: > > end, I gave up and used a system without NM or any of the other stuff, > > That's the right answer: simply turn off NetworkManager and turn on the > "network" service, to prevent these new breakages from occurring. I do > that for all the machines in my test lab. For clarification, I usually do have NM_CONTROLLED set for every interface, except on laptops. In this case, I just wanted to instead turn off NetworkManager and configure the interface manually. I see no reason why it shouldn't be possible to tell a system service to stop and expect it to stay stopped until I turn it back on again. That way, I can tell NM to shutdown, do something I need to do, then get the prettified laptop experience back again when I'm done (on the netbook). This was all to tftp various firmwares over to routers I was playing with over the weekend. Soldering surface mount bits, placing wires, and poking at serial consoles and firmware setup was trivial. The hardest bit was telling a system service to stay stopped :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On 03/29/2011 07:35 AM, Jeff Raber wrote: > On 03/27/2011 10:57 AM, Ralf Corsepius wrote: >> And how to tweak /etc/sysconfig/network-scripts/ifcfg-* (and/or >> /etc/sysconfig/network) for static IPs such that NM sets >> hostname/domainname correctly? >> >> I have never got this working correctly. >> >> In all cases, I've tried either "hostname -f" or "hostname" did not work. > > https://bugzilla.redhat.com/show_bug.cgi?id=648725#c23 Thanks for the hint. > Sounds like NM is out of the 'hostname setting' business. You should be > able to edit your /etc/hosts manually and NM will not change it. This would be good news. So far, my work around with static IPs had been to modify /etc/nsswitch.conf to let it ignore "file" and to rely on dns only. Not necessarily nice, but it appears to be working (at least for me). Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On 03/27/2011 10:57 AM, Ralf Corsepius wrote: > And how to tweak /etc/sysconfig/network-scripts/ifcfg-* (and/or > /etc/sysconfig/network) for static IPs such that NM sets > hostname/domainname correctly? > > I have never got this working correctly. > > In all cases, I've tried either "hostname -f" or "hostname" did not work. https://bugzilla.redhat.com/show_bug.cgi?id=648725#c23 Sounds like NM is out of the 'hostname setting' business. You should be able to edit your /etc/hosts manually and NM will not change it. -Jeff signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 17:59 -0400, Jon Masters wrote: > On Sat, 2011-03-26 at 11:03 -0400, Neil Horman wrote: > > > IIRC you can set: > > NM_CONTROLLED="no" > > in /etc/sysconfig/network-scripts/ifcfg-ethX > > Supposedly that will take ethX off the reservation and allow you to use the > > ifup > > script and ifconfig utility as you traditionally would. > > I remain unconvinced that in rawhide it's possibly to truly instruct all > these wonderful bells and whistles to leave an interface alone. In the That's exactly what the very simple NM_CONTROLLED key is supposed to do. If it doesn't do that, then file a bug. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
Jon Masters (jonat...@jonmasters.org) said: > Right. This is exactly what I do on non-laptops. But I find NM useful > for WiFi sometimes so I keep it installed...but now it seems it's > becoming very difficult to just temporarily configure an interface that > won't be touched when I plug/unplug a cable or whatnot. > > Really, there should be a better way that turning off every network > service and script for the 5 minutes I want this. I have other machines, > etc. and this is rawhide, but it's also the future. It depends on what you want to do. If you want NM to never touch your wired device, add: NM_CONTROLLED="no" to its config file. If you want that device to just have a static IP, edit the config file appropriately, and NM will handle that. If you want to disable NM entirely, 'systemctl disable NetworkManager.service'. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On 03/26/2011 05:59 PM, Jon Masters wrote: > On Sat, 2011-03-26 at 11:03 -0400, Neil Horman wrote: > >> IIRC you can set: >> NM_CONTROLLED="no" >> in /etc/sysconfig/network-scripts/ifcfg-ethX >> Supposedly that will take ethX off the reservation and allow you to use the >> ifup >> script and ifconfig utility as you traditionally would. > > I remain unconvinced that in rawhide it's possibly to truly instruct all > these wonderful bells and whistles to leave an interface alone. In the You should try what Neil suggested; it works. > end, I gave up and used a system without NM or any of the other stuff, That's the right answer: simply turn off NetworkManager and turn on the "network" service, to prevent these new breakages from occurring. I do that for all the machines in my test lab. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, Mar 26, 2011 at 5:59 PM, Jon Masters wrote: > On Sat, 2011-03-26 at 11:03 -0400, Neil Horman wrote: > >> IIRC you can set: >> NM_CONTROLLED="no" >> in /etc/sysconfig/network-scripts/ifcfg-ethX >> Supposedly that will take ethX off the reservation and allow you to use the >> ifup >> script and ifconfig utility as you traditionally would. > > I remain unconvinced that in rawhide it's possibly to truly instruct all > these wonderful bells and whistles to leave an interface alone. So you're not even going to try what he suggests? Why? Easier to just keep posting to fedora-devel-list? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On 03/27/2011 05:27 PM, Chuck Anderson wrote: > On Sun, Mar 27, 2011 at 03:58:06PM +0200, Ralf Ertzinger wrote: >> Hi. >> >> On Sun, 27 Mar 2011 15:48:14 +0200, Kevin Kofler wrote >>> NM supports static IPs these days. So I think that rather than >>> hacking around NM, you should just fix the IP inside NM's >>> configuration and have NM work FOR you rather than AGAINST you. >> >> I'm sorry, but by the time I have clicked through the GUI to do >> that I have configured the interface via ip, did what I wanted to >> do and unconfigured the interface again. >> >> I uncheck "Enable networking" in nm-applet before doing that, >> and for me that makes NM keep it's grubby paws off my manually >> configured interface, so I'm not complaining. > > You don't need to use the GUI. Just edit > /etc/sysconfig/network-scripts/ifcfg-* with a static IP and NM will > pick it up right away and configure it. And how to tweak /etc/sysconfig/network-scripts/ifcfg-* (and/or /etc/sysconfig/network) for static IPs such that NM sets hostname/domainname correctly? I have never got this working correctly. In all cases, I've tried either "hostname -f" or "hostname" did not work. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sun, Mar 27, 2011 at 03:58:06PM +0200, Ralf Ertzinger wrote: > Hi. > > On Sun, 27 Mar 2011 15:48:14 +0200, Kevin Kofler wrote > > NM supports static IPs these days. So I think that rather than > > hacking around NM, you should just fix the IP inside NM's > > configuration and have NM work FOR you rather than AGAINST you. > > I'm sorry, but by the time I have clicked through the GUI to do > that I have configured the interface via ip, did what I wanted to > do and unconfigured the interface again. > > I uncheck "Enable networking" in nm-applet before doing that, > and for me that makes NM keep it's grubby paws off my manually > configured interface, so I'm not complaining. You don't need to use the GUI. Just edit /etc/sysconfig/network-scripts/ifcfg-* with a static IP and NM will pick it up right away and configure it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
Hi. On Sun, 27 Mar 2011 15:48:14 +0200, Kevin Kofler wrote > NM supports static IPs these days. So I think that rather than > hacking around NM, you should just fix the IP inside NM's > configuration and have NM work FOR you rather than AGAINST you. I'm sorry, but by the time I have clicked through the GUI to do that I have configured the interface via ip, did what I wanted to do and unconfigured the interface again. I uncheck "Enable networking" in nm-applet before doing that, and for me that makes NM keep it's grubby paws off my manually configured interface, so I'm not complaining. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
NM supports static IPs these days. So I think that rather than hacking around NM, you should just fix the IP inside NM's configuration and have NM work FOR you rather than AGAINST you. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 11:03 -0400, Neil Horman wrote: > IIRC you can set: > NM_CONTROLLED="no" > in /etc/sysconfig/network-scripts/ifcfg-ethX > Supposedly that will take ethX off the reservation and allow you to use the > ifup > script and ifconfig utility as you traditionally would. I remain unconvinced that in rawhide it's possibly to truly instruct all these wonderful bells and whistles to leave an interface alone. In the end, I gave up and used a system without NM or any of the other stuff, since turning it off for a few minutes was getting too involved. On that other system, adding a manual ARP entry and an interface alias with another IP stuck, didn't change randomly, and did what I wanted. Not very web 2.0 I know, but I like it that way. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, Mar 26, 2011 at 07:24:24AM -0400, Jon Masters wrote: > On Sat, 2011-03-26 at 12:10 +0100, Michel Alexandre Salim wrote: > > On 03/26/2011 12:05 PM, Jon Masters wrote: > > > Then it became necessary to: > > > > > > /etc/init.d/NetworkManager stop > > > > > > Then it became necessary to: > > > > > > systemctl disable NetworkManager.service > > > > The last two are equivalent to "service NetworkManager stop", which > > still works even with systemd. > > Nope. It doesn't :) I tried that, and as I said, NM restarted > immediately. The only way to stop it was to disable the service, and > even then something was unconfiguring the port on link loss. Argh. > > Jon. > IIRC you can set: NM_CONTROLLED="no" in /etc/sysconfig/network-scripts/ifcfg-ethX Supposedly that will take ethX off the reservation and allow you to use the ifup script and ifconfig utility as you traditionally would. Neil > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 07:05 -0400, Jon Masters wrote: > So, back in the good old days, one could just type this: > Just to try to get the interface left alone. Isn't "the way" just to put NM_CONTROLLED=no in the relevant interface config file? Even if you're not statically configuring an actual network at that point it should leave the device alone. Ta Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 12:23 +0100, Reindl Harald wrote: > Nobody stops you to disable Network-Manager, DHCP, AVAHI and the other > noob-crap > and write your /etc/sysconfig/network-scripts/ifcfg-eth0 manually as i do > everytime directly after the first boot and i guess the next 20 years > this will be the same on a unix-like system Right. This is exactly what I do on non-laptops. But I find NM useful for WiFi sometimes so I keep it installed...but now it seems it's becoming very difficult to just temporarily configure an interface that won't be touched when I plug/unplug a cable or whatnot. Really, there should be a better way that turning off every network service and script for the 5 minutes I want this. I have other machines, etc. and this is rawhide, but it's also the future. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
Am 26.03.2011 12:24, schrieb Jon Masters: > On Sat, 2011-03-26 at 12:10 +0100, Michel Alexandre Salim wrote: >> On 03/26/2011 12:05 PM, Jon Masters wrote: >>> Then it became necessary to: >>> >>> /etc/init.d/NetworkManager stop >>> >>> Then it became necessary to: >>> >>> systemctl disable NetworkManager.service >> >> The last two are equivalent to "service NetworkManager stop", which >> still works even with systemd. > > Nope. It doesn't :) I tried that, and as I said, NM restarted > immediately. The only way to stop it was to disable the service, and > even then something was unconfiguring the port on link loss. Argh. * prepare your static configuration * send all commands to stop/dsiable/start/mv in one line * your network is running signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
Am 26.03.2011 12:05, schrieb Jon Masters: > Hello, > > So, back in the good old days, one could just type this: > > ifconfig eth0 some_temp_ip up > > Then it became necessary to: > > /etc/init.d/NetworkManager stop > > Then it became necessary to: > > systemctl disable NetworkManager.service > > Just to try to get the interface left alone. > > But when the link it's attached to drops, the settings are immediately > being dropped and the interface unconfigured. So, what have I missed? > What's the other thing that's trying to be all "helpful" but actually > preventing me from running TFTP usefully? Sure, I could plug it into a > switch and go all Windows 95 on this, but...I'd rather not. Nobody stops you to disable Network-Manager, DHCP, AVAHI and the other noob-crap and write your /etc/sysconfig/network-scripts/ifcfg-eth0 manually as i do everytime directly after the first boot and i guess the next 20 years this will be the same on a unix-like system the whole network-config can be like this replace 127.0.0.1 by your namservers, disable all things you do not need and type * chkconfig network on * service network start after the basic configuration [root@srv-rhsoft:~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 IPADDR=192.168.1.2 NETWORK=192.168.1.0 GATEWAY=192.168.1.1 BROADCAST=192.168.1.255 NETMASK=255.255.255.0 TYPE=Ethernet BOOTPROTO=static ONBOOT=yes NM_CONTROLLED=no USERCTL=no IPV6INIT=no [root@srv-rhsoft:~]$ cat /etc/resolv.conf nameserver 127.0.0.1 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 12:10 +0100, Michel Alexandre Salim wrote: > On 03/26/2011 12:05 PM, Jon Masters wrote: > > Then it became necessary to: > > > > /etc/init.d/NetworkManager stop > > > > Then it became necessary to: > > > > systemctl disable NetworkManager.service > > The last two are equivalent to "service NetworkManager stop", which > still works even with systemd. Nope. It doesn't :) I tried that, and as I said, NM restarted immediately. The only way to stop it was to disable the service, and even then something was unconfiguring the port on link loss. Argh. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
Jon, have you seen nmcli? If you can't do what you want to with it, maybe a feature request is in order. I get the impression that NM will generally do the right thing for most people most of the time, and when we are hacking on firmware, running a tftp server and the like we might want to use nmcli to take a device temporarily from NM's clutches and take manual control. I'm not sure it that's possible though with the current nmcli. I tried nmcli dev disconnect iface eth0 on my netbook which was connected to wlan0 and had nothing on eth0 - it errored saying that eth0 wasn't active to start with. I think keeping NM running for the system is a good thing, taking one device over for your own purposes is a better thing to do *if possible* than disabling NM entirely. -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On 03/26/2011 12:05 PM, Jon Masters wrote: > Then it became necessary to: > > /etc/init.d/NetworkManager stop > > Then it became necessary to: > > systemctl disable NetworkManager.service The last two are equivalent to "service NetworkManager stop", which still works even with systemd. -- Michel Alexandre Salim () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
manually fixing IPs
Hello, So, back in the good old days, one could just type this: ifconfig eth0 some_temp_ip up Then it became necessary to: /etc/init.d/NetworkManager stop Then it became necessary to: systemctl disable NetworkManager.service Just to try to get the interface left alone. But when the link it's attached to drops, the settings are immediately being dropped and the interface unconfigured. So, what have I missed? What's the other thing that's trying to be all "helpful" but actually preventing me from running TFTP usefully? Sure, I could plug it into a switch and go all Windows 95 on this, but...I'd rather not. Thanks, Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
