9:21 a.m.
Hi,
The standard "list of bugs found on upgrade" mail, I'll file these in
bugzilla in a bit. This was a "yum update" fc2->rawhide, which yum
handled nicely.
The hardware is IBM X31 with builtin e100 and airo network.
- rescanning pixbuf loaders (on installing gtk2, libwmf for example) I
got "undefined symbol TiffReadRGBAImageOriented" in the tiff loader;
maybe gtk2 needs to prereq a newer version of libtiff or something
- on login, "failed to load image gcalctool.png" - this is a standard
problem, what if people are using an image in a launcher and we
rename/delete said image
- X configuration defaults to 800x600 instead of 1024x768, because
the monitor can't be probed. result = fugly; I *thought* older
releases defaulted to 1024, but I could be wrong.
- when running kudzu under rhgb, arrow keys are screwed; they mangle
the display - this is on the TCP configuration screen
- choosing "Back" on the TCP config screen seems to just cancel,
instead of going back
- kudzu used eth1 and eth2 instead of eth0 and eth1 for the
two network cards; more oddly, sometimes it gets it right but
on reboot it seems to remove eth0 and add eth2. Also, it insists that
airo has to be eth0, and e100 eth1, while in FC2 it insisted the
opposite. I've been deleting modprobe.conf, hwconfig,
sysconfig/networking/devices/*, sysconfig/network-scripts/ifcfg-*,
sysconfig/networking/profiles/default/* and rebooting over
and over trying to get a correct config to be autodetected and
"stick", no luck yet
- bringing up an interface creates an empty resolv.conf.
Writing a correct resolv.conf results in working network,
so the dhcp succeeds, resolv.conf is just hosed.
- the battery applet has the wrong suspend command;
"/usr/bin/apm -s"
- _is_ there a suspend command that works for both
apm and acpi? If not I suggest we add one...
the "echo > /proc/acpi/sleep" thing is just
embarrassing anyway
Havoc
9:27 a.m.
Hi,
Also
- nothing pulled in gnome-volume-manager; we need a Requires: from
nautilus or whatever
Havoc
3:21 p.m.
On Sun, 2004-08-22 at 10:31 -0400, Havoc Pennington wrote:
On Sun, 2004-08-22 at 10:27 -0400, Havoc Pennington wrote:
> Hi,
>
> Also
>
> - nothing pulled in gnome-volume-manager; we need a Requires: from
> nautilus or whatever
>
(I suppose it obsoletes/provides magicdev, but yum doesn't seem to
handle that; maybe in "yum upgrade" mode only)
yes yum upgrade pulls in obsoletes.
I'm working on the code right now for yum-HEAD for
"yum --obsoletes update"
so that you can run an update and still have it include obsoletes.
essentially it's the same as yum upgrade but w/o changing the base
command.
-sv
3:10 p.m.
On Sun, 2004-08-22 at 16:21, Havoc Pennington wrote:
- on login, "failed to load image gcalctool.png" - this is
a standard
problem, what if people are using an image in a launcher and we
rename/delete said image
This could be dealt with like this: In the DEs when adding a launcher,
_copy_ an icon if it isn't owned by the current user. In the case of
root, we'd have to decide whether to copy always or never.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
6:47 p.m.
On Sun, 2004-08-22 at 22:10 +0200, Nils Philippsen wrote:
On Sun, 2004-08-22 at 16:21, Havoc Pennington wrote:
> - on login, "failed to load image gcalctool.png" - this is a standard
> problem, what if people are using an image in a launcher and we
> rename/delete said image
This could be dealt with like this: In the DEs when adding a launcher,
_copy_ an icon if it isn't owned by the current user. In the case of
root, we'd have to decide whether to copy always or never.
Indeed, that's how we avoid the problem for the .desktop file itself.
Good point.
Havoc
8:37 p.m.
On Sun, 2004-08-22 at 10:21 -0400, Havoc Pennington wrote:
- kudzu used eth1 and eth2 instead of eth0 and eth1 for the
two network cards; more oddly, sometimes it gets it right but
on reboot it seems to remove eth0 and add eth2. Also, it insists that
airo has to be eth0, and e100 eth1, while in FC2 it insisted the
opposite. I've been deleting modprobe.conf, hwconfig,
sysconfig/networking/devices/*, sysconfig/network-scripts/ifcfg-*,
sysconfig/networking/profiles/default/* and rebooting over
and over trying to get a correct config to be autodetected and
"stick", no luck yet
BTW, when using NetworkManager for desktops, do we really need network-
scripts and sysconfig/networking at all?
It feels to me like many problems I've had with networking have come
down to the fact that the configuration is in multiple places:
modprobe.conf, hwconf, network-scripts, sysconfig/networking;
it doesn't seem that well-defined how it all works... maybe I'm just
dense though.
One policy we might try to get closer to: clearly split autogenerated
information from manually-edited information, and machine-readable
information from human-only information such as scripts.
Havoc
9:02 p.m.
On Sunday 22 August 2004 21:37, Havoc Pennington wrote:
On Sun, 2004-08-22 at 10:21 -0400, Havoc Pennington wrote:
> - kudzu used eth1 and eth2 instead of eth0 and eth1 for the
> two network cards; more oddly, sometimes it gets it right but
> on reboot it seems to remove eth0 and add eth2. Also, it insists that
> airo has to be eth0, and e100 eth1, while in FC2 it insisted the
> opposite. I've been deleting modprobe.conf, hwconfig,
> sysconfig/networking/devices/*, sysconfig/network-scripts/ifcfg-*,
> sysconfig/networking/profiles/default/* and rebooting over
> and over trying to get a correct config to be autodetected and
> "stick", no luck yet
We've had the same issue with a couple of
via-rhine and realtec 8139
cards... The problem seems to be that the driver does not allow you to
read certain things like mac address unless the interface is actually up.
I've hacked a kudzu version that - if the interface is not up, it will being
it up and then after the check, shuts it down again. I'm aware that that's
not a good solution and the code I put in there is probably among the
worst you've ever seen (it uses system without checking the parameters
and stuff like that) but it was only done as a proof of bug :-) We're using
it on a couple of systems here and if you just need to make it work without
worrying about how it looks, this might be ok for you.
Try http://www.dealrover.com/kudzu-1.1.22-1.1.centos.0.src.rpm and let me
know if that fixes your issue. Last time I brought this up on this list, I was
told that it wasn't a kudzu issue but that the driver needs fixing.
One policy we might try to get closer to: clearly split
autogenerated
information from manually-edited information, and machine-readable
information from human-only information such as scripts.
That would be a great idea but if you auto-generated information once, then
why not do it every time? Yes, it might add a milisecond to the startup time
but at least that would not litter your files with stuff that the system has
the ability to figure out by itsself anyway.
Peter.
--
http://www.dealrover.com
6:48 a.m.
On Sun, Aug 22, 2004 at 10:02:54PM -0400, Peter Arremann wrote:
We've had the same issue with a couple of via-rhine and realtec
8139
cards... The problem seems to be that the driver does not allow you to
read certain things like mac address unless the interface is actually up.
We've been kicking around the idea that this should in fact become
mandatory.
know if that fixes your issue. Last time I brought this up on this
list, I was
told that it wasn't a kudzu issue but that the driver needs fixing.
The problem with that view (which indeed was certainly my view and I fixed
some drivers) is that from "up" it can take 60 seconds to get gigabit
negotiation completed. In addition it really mucks up power management
code in all the drivers.
Everything else has "open it, do stuff, close it". Making kudzu do this
would fix a lot of bugs, and indeed SuSE seem to follow that rule in yast
6:56 a.m.
On Mon, 2004-08-23 at 12:48, Alan Cox wrote:
The problem with that view (which indeed was certainly my view and I
fixed
some drivers) is that from "up" it can take 60 seconds to get gigabit
negotiation completed. In addition it really mucks up power management
code in all the drivers.
I have a set of IBM servers with E1000 type ethernet NICs onboard which
are incapable of DHCP because they take longer to negotiate onto the
network than the DHCP timeouts. More amusingly, if coupled with cisco
switches they can badly negotiate to a state where ping and packet
turn-round time is of the order of 10 seconds. Where the hell it stores
the data I have no idea...
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham(a)InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
7:38 a.m.
On Mon, 2004-08-23 at 13:56, Nigel Metheringham wrote:
On Mon, 2004-08-23 at 12:48, Alan Cox wrote:
> The problem with that view (which indeed was certainly my view and I fixed
> some drivers) is that from "up" it can take 60 seconds to get gigabit
> negotiation completed. In addition it really mucks up power management
> code in all the drivers.
I have a set of IBM servers with E1000 type ethernet NICs onboard which
are incapable of DHCP because they take longer to negotiate onto the
network than the DHCP timeouts.
IIRC this should set timeout to 120 seconds on eth0:
echo "timeout 120;" >> /etc/dhclient-eth0.conf
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
4:50 p.m.
On Mon, 2004-08-23 at 05:56, Nigel Metheringham wrote:
On Mon, 2004-08-23 at 12:48, Alan Cox wrote:
> The problem with that view (which indeed was certainly my view and I fixed
> some drivers) is that from "up" it can take 60 seconds to get gigabit
> negotiation completed. In addition it really mucks up power management
> code in all the drivers.
I have a set of IBM servers with E1000 type ethernet NICs onboard which
are incapable of DHCP because they take longer to negotiate onto the
network than the DHCP timeouts. More amusingly, if coupled with cisco
switches they can badly negotiate to a state where ping and packet
turn-round time is of the order of 10 seconds. Where the hell it stores
the data I have no idea...
It isn't just NIC to switch negotiation.
What I've seen in many many environments is the spanning tree protocol
is-there-a-layer-2-loop detection taking longer than the DHCP client
will wait.
I wager that spanning tree is the bigger problem vs ethernet
negotiation.
Dax Kelson
Guru Labs
8:30 a.m.
On Mon, 2004-08-23 at 07:48 -0400, Alan Cox wrote:
On Sun, Aug 22, 2004 at 10:02:54PM -0400, Peter Arremann wrote:
> We've had the same issue with a couple of via-rhine and realtec 8139
> cards... The problem seems to be that the driver does not allow you to
> read certain things like mac address unless the interface is actually up.
We've been kicking around the idea that this should in fact become
mandatory.
> know if that fixes your issue. Last time I brought this up on this list, I was
> told that it wasn't a kudzu issue but that the driver needs fixing.
The problem with that view (which indeed was certainly my view and I fixed
some drivers) is that from "up" it can take 60 seconds to get gigabit
negotiation completed.
This definitely sucks from a UI point of view. We will need to provide
progress feedback to the user somehow. Probably autodetect "is this
gigabit", and if so, NetworkManager could pop up a dialog perhaps with a
cancel button. If you hit cancel it would fall back to wireless.
8:53 a.m.
On Mon, 2004-08-23 at 15:30, Colin Walters wrote:
On Mon, 2004-08-23 at 07:48 -0400, Alan Cox wrote:
> On Sun, Aug 22, 2004 at 10:02:54PM -0400, Peter Arremann wrote:
> > We've had the same issue with a couple of via-rhine and realtec 8139
> > cards... The problem seems to be that the driver does not allow you to
> > read certain things like mac address unless the interface is actually up.
>
> We've been kicking around the idea that this should in fact become
> mandatory.
>
> > know if that fixes your issue. Last time I brought this up on this list, I was
> > told that it wasn't a kudzu issue but that the driver needs fixing.
>
> The problem with that view (which indeed was certainly my view and I fixed
> some drivers) is that from "up" it can take 60 seconds to get gigabit
> negotiation completed.
This definitely sucks from a UI point of view. We will need to provide
progress feedback to the user somehow. Probably autodetect "is this
gigabit", and if so, NetworkManager could pop up a dialog perhaps with a
cancel button. If you hit cancel it would fall back to wireless.
It would be really great if GE-hardware could just start in FE-mode
which is quick enough and negotiate GE in the background, starting
slower and increasing speed if possible. Unfortunately that train has
departed already...
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
1:39 p.m.
Alan Cox (alan(a)redhat.com) said:
Everything else has "open it, do stuff, close it". Making
kudzu do this
would fix a lot of bugs, and indeed SuSE seem to follow that rule in yast
All kudzu is doing is running the ethtool 'tell me what driver you have'
ioctl. Which shouldn't really care one whit about the card's state.
Bill
2:47 p.m.
On Mon, Aug 23, 2004 at 02:39:41PM -0400, Bill Nottingham wrote:
Alan Cox (alan(a)redhat.com) said:
> Everything else has "open it, do stuff, close it". Making kudzu do this
> would fix a lot of bugs, and indeed SuSE seem to follow that rule in yast
All kudzu is doing is running the ethtool 'tell me what driver you have'
ioctl. Which shouldn't really care one whit about the card's state.
ethtool only works rationally for several cards if the interface is already
up (and preferably has been for a few seconds). I'm not sure what needs
changing for our boot behaviour but that is the reality.
Alan
3:01 p.m.
Alan Cox (alan(a)redhat.com) said:
> All kudzu is doing is running the ethtool 'tell me what
driver you have'
> ioctl. Which shouldn't really care one whit about the card's state.
ethtool only works rationally for several cards if the interface is already
up (and preferably has been for a few seconds). I'm not sure what needs
changing for our boot behaviour but that is the reality.
But the ioctl has *nothing to do with the card state*. It doesn't touch
any registers, all it does is look at a driver-internal field.
Bill
3:05 p.m.
On Mon, Aug 23, 2004 at 04:01:05PM -0400, Bill Nottingham wrote:
> ethtool only works rationally for several cards if the interface
is already
> up (and preferably has been for a few seconds). I'm not sure what needs
> changing for our boot behaviour but that is the reality.
But the ioctl has *nothing to do with the card state*. It doesn't touch
any registers, all it does is look at a driver-internal field.
Except for a couple of ioctls like DRVINFO this isnt true. Some cards
do maintain link state in D3, others don't bother which means we can't just
flip the chip on and off.
Alan
3:14 p.m.
Alan Cox (alan(a)redhat.com) said:
On Mon, Aug 23, 2004 at 04:01:05PM -0400, Bill Nottingham wrote:
> > ethtool only works rationally for several cards if the interface is already
> > up (and preferably has been for a few seconds). I'm not sure what needs
> > changing for our boot behaviour but that is the reality.
>
> But the ioctl has *nothing to do with the card state*. It doesn't touch
> any registers, all it does is look at a driver-internal field.
Except for a couple of ioctls like DRVINFO this isnt true.
That's what I'm saying. The only ethtool ioctl kudzu uses is GDRVINFO.
Bill
3:26 p.m.
On Mon, Aug 23, 2004 at 04:14:03PM -0400, Bill Nottingham wrote:
Alan Cox (alan(a)redhat.com) said:
> Except for a couple of ioctls like DRVINFO this isnt true.
That's what I'm saying. The only ethtool ioctl kudzu uses is GDRVINFO.
That one is ok then. In which case its whoever else is poking MII and link
status after kudzu
9:10 p.m.
On Sun, 22 Aug 2004, Havoc Pennington wrote:
BTW, when using NetworkManager for desktops, do we really need
network-
scripts and sysconfig/networking at all?
It feels to me like many problems I've had with networking have come
down to the fact that the configuration is in multiple places:
modprobe.conf, hwconf, network-scripts, sysconfig/networking;
it doesn't seem that well-defined how it all works... maybe I'm just
dense though.
One policy we might try to get closer to: clearly split autogenerated
information from manually-edited information, and machine-readable
information from human-only information such as scripts.
NetworkManager doesn't really care what the interfaces are named of
course, so that problem should be solved. I can see two problems with
skipping the config stuff in network-scripts and sysconfig-networking:
1) kernel module autoloading. Current process: /etc/rc.d/init.d/network
loads the kernel modules itself by reading
sysconfig/network-scripts/ifcfg-* and reading the device, then asks
modprobe (which reads modprobe.conf) what the device name is, then has
modprobe load it. NetworkManager process: asks hal for network devices.
Unfortunately, hal doesn't know that a device is network device until its
kernel module is loaded, which never happens. So we have to keep the
ifcfg-* stuff around until we start autoloading kernel modules when the
device is present (which sounds just fine to me).
2) NetworkManager will eventually have to deal with static IP information,
which means we need the stuff like IP, gateway, DNS, and perhaps YP
information which has to get stored somewhere, and is currently in the
ifcfg-* files.
Dan
9:14 p.m.
NetworkManager doesn't really care what the interfaces are named
of
course, so that problem should be solved. I can see two problems with
skipping the config stuff in network-scripts and sysconfig-networking:
1) kernel module autoloading. Current process: /etc/rc.d/init.d/network
loads the kernel modules itself by reading
sysconfig/network-scripts/ifcfg-* and reading the device, then asks
modprobe (which reads modprobe.conf) what the device name is, then has
modprobe load it. NetworkManager process: asks hal for network devices.
Unfortunately, hal doesn't know that a device is network device until its
kernel module is loaded, which never happens. So we have to keep the
ifcfg-* stuff around until we start autoloading kernel modules when the
device is present (which sounds just fine to me).
Not fine to a lot of servers, though. Sometimes you have multiple nics
in a machine and you don't want certain ones even coming up if you can
avoid it. Maybe they're a heartbeat backup nic or maybe they're an
onboard nic that plays hell with your bios. It doesn't matter, simply
loading a driver b/c the device is in the machine will piss off a lot of
people who appreciate being able to control what their system does.
-sv
9:32 p.m.
On Sun, 22 Aug 2004, seth vidal wrote:
Not fine to a lot of servers, though. Sometimes you have multiple
nics
in a machine and you don't want certain ones even coming up if you can
avoid it. Maybe they're a heartbeat backup nic or maybe they're an
onboard nic that plays hell with your bios. It doesn't matter, simply
loading a driver b/c the device is in the machine will piss off a lot of
people who appreciate being able to control what their system does.
Ditto. This would mightily suck and cause "bad things" to happen on a
number of my machines.
-n
--
-------------------------------------------
nathan hruby <nhruby(a)uga.edu>
uga enterprise information technology services
production systems support
metaphysically wrinkle-free
-------------------------------------------
9:39 p.m.
On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote:
Not fine to a lot of servers, though. Sometimes you have multiple
nics
in a machine and you don't want certain ones even coming up if you can
avoid it. Maybe they're a heartbeat backup nic or maybe they're an
onboard nic that plays hell with your bios. It doesn't matter, simply
loading a driver b/c the device is in the machine will piss off a lot of
people who appreciate being able to control what their system does.
I very carefully said "on desktops" and "the config files would be used
if present" ;-)
Havoc
9:39 p.m.
On Sun, 2004-08-22 at 22:39 -0400, Havoc Pennington wrote:
On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote:
> Not fine to a lot of servers, though. Sometimes you have multiple nics
> in a machine and you don't want certain ones even coming up if you can
> avoid it. Maybe they're a heartbeat backup nic or maybe they're an
> onboard nic that plays hell with your bios. It doesn't matter, simply
> loading a driver b/c the device is in the machine will piss off a lot of
> people who appreciate being able to control what their system does.
>
>
I very carefully said "on desktops" and "the config files would be used
if present" ;-)
I must have very carefully ignored them.
<sheepish>
sorry
</sheepish>
-sv
9:59 p.m.
On Sun, 2004-08-22 at 22:39 -0400, seth vidal wrote:
On Sun, 2004-08-22 at 22:39 -0400, Havoc Pennington wrote:
> I very carefully said "on desktops" and "the config files would be
used
> if present" ;-)
>
I must have very carefully ignored them.
Re-reading my mail it's more like I carefully *intended* to say that, I
guess. ;-)
Havoc
6:50 a.m.
On Sun, Aug 22, 2004 at 10:39:56PM -0400, Havoc Pennington wrote:
On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote:
> Not fine to a lot of servers, though. Sometimes you have multiple nics
> in a machine and you don't want certain ones even coming up if you can
> avoid it. Maybe they're a heartbeat backup nic or maybe they're an
> onboard nic that plays hell with your bios. It doesn't matter, simply
> loading a driver b/c the device is in the machine will piss off a lot of
> people who appreciate being able to control what their system does.
>
I very carefully said "on desktops" and "the config files would be used
if present" ;-)
netplugd seems to work well in that kind of environment so providing the
config files are used if there probably. Of course you've still got to work
out what config file goes with what device and what is for networkmangler 8)
9:59 p.m.
On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote:
Not fine to a lot of servers, though. Sometimes you have multiple
nics
in a machine and you don't want certain ones even coming up if you can
avoid it. Maybe they're a heartbeat backup nic
Loading the driver doesn't mean assigning an address to it. I don't see
how simply having the driver loaded would cause problems for a backup
NIC.
or maybe they're an
onboard nic that plays hell with your bios.
That just sounds like a bug.
10:01 p.m.
> Not fine to a lot of servers, though. Sometimes you have
multiple nics
> in a machine and you don't want certain ones even coming up if you can
> avoid it. Maybe they're a heartbeat backup nic
Loading the driver doesn't mean assigning an address to it. I don't see
how simply having the driver loaded would cause problems for a backup
NIC.
loading the driver means activating the device, which typically means
the network (especially switches) are suddenly aware of it.
That can be real bad in heartbeat configurations when you want to load
it as different hw address on failure.
> or maybe they're an
> onboard nic that plays hell with your bios.
That just sounds like a bug.
bug or not, loading a driver just b/c a device is present is a good way
to make A LOT of systems unbootable. I'll point you to thousands of
video cards as an example.
-sv
10:32 p.m.
On Sun, 2004-08-22 at 23:01 -0400, seth vidal wrote:
> > Not fine to a lot of servers, though. Sometimes you have
multiple nics
> > in a machine and you don't want certain ones even coming up if you can
> > avoid it. Maybe they're a heartbeat backup nic
>
> Loading the driver doesn't mean assigning an address to it. I don't see
> how simply having the driver loaded would cause problems for a backup
> NIC.
loading the driver means activating the device, which typically means
the network (especially switches) are suddenly aware of it.
Ok. But certainly heartbeat is a special case - you have to do some
manual configuration, and whatever program we have to load drivers could
certainly provide a blacklist.
bug or not, loading a driver just b/c a device is present is a good
way
to make A LOT of systems unbootable.
I've never had problems personally when I ran Debian, they use discover,
which IIRC autoloads modules for anything it knows about.
I'll point you to thousands of
video cards as an example.
The kernel already has blacklists for bad devices, sounds like that
needs to grow...
6:51 a.m.
On Sun, Aug 22, 2004 at 10:59:59PM -0400, Colin Walters wrote:
On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote:
> Not fine to a lot of servers, though. Sometimes you have multiple nics
> in a machine and you don't want certain ones even coming up if you can
> avoid it. Maybe they're a heartbeat backup nic
Loading the driver doesn't mean assigning an address to it. I don't see
how simply having the driver loaded would cause problems for a backup
NIC.
> or maybe they're an
> onboard nic that plays hell with your bios.
That just sounds like a bug.
A few of those around. More typically the problem is that you end up on
wireless when you wanted to be on ethernet and all of a sudden your
perceived "I plugged the wire in" security is worthless
7:21 a.m.
On Mon, 2004-08-23 at 07:51 -0400, Alan Cox wrote:
On Sun, Aug 22, 2004 at 10:59:59PM -0400, Colin Walters wrote:
> On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote:
> > Not fine to a lot of servers, though. Sometimes you have multiple nics
> > in a machine and you don't want certain ones even coming up if you can
> > avoid it. Maybe they're a heartbeat backup nic
>
> Loading the driver doesn't mean assigning an address to it. I don't see
> how simply having the driver loaded would cause problems for a backup
> NIC.
>
> > or maybe they're an
> > onboard nic that plays hell with your bios.
>
> That just sounds like a bug.
A few of those around. More typically the problem is that you end up on
wireless when you wanted to be on ethernet
Because somehow your wireless driver kills your ethernet card or
something?
and all of a sudden your
perceived "I plugged the wire in" security is worthless
I don't think there should be any expectation of security from being on
a wired network, and certainly we should not design with that
assumption. NetworkManager just prefers wired networks because they're
presumably faster.
7:30 a.m.
On Mon, Aug 23, 2004 at 08:21:45AM -0400, Colin Walters wrote:
> A few of those around. More typically the problem is that you
end up on
> wireless when you wanted to be on ethernet
Because somehow your wireless driver kills your ethernet card or
something?
Because you've got to pick between the two and you may pick wrongly
I don't think there should be any expectation of security from
being on
a wired network, and certainly we should not design with that
assumption. NetworkManager just prefers wired networks because they're
presumably faster.
Ok so it picks the right choice at least. In many businesses there is an
expectation of security on the wired network and its reasonably for there
to be.
Alan
10:57 p.m.
On Sun, 22 Aug 2004, Havoc Pennington wrote:
On Sun, 2004-08-22 at 10:21 -0400, Havoc Pennington wrote:
>
> - kudzu used eth1 and eth2 instead of eth0 and eth1 for the
> two network cards; more oddly, sometimes it gets it right but
> on reboot it seems to remove eth0 and add eth2. Also, it insists that
> airo has to be eth0, and e100 eth1, while in FC2 it insisted the
> opposite. I've been deleting modprobe.conf, hwconfig,
> sysconfig/networking/devices/*, sysconfig/network-scripts/ifcfg-*,
> sysconfig/networking/profiles/default/* and rebooting over
> and over trying to get a correct config to be autodetected and
> "stick", no luck yet
BTW, when using NetworkManager for desktops, do we really need network-
scripts and sysconfig/networking at all?
I am a little confused. Does this mean you would have a different network
config scheme for desktops as opposed to servers?
It feels to me like many problems I've had with networking have come
down to the fact that the configuration is in multiple places:
modprobe.conf, hwconf, network-scripts, sysconfig/networking;
it doesn't seem that well-defined how it all works... maybe I'm just
dense though.
I agree it is not well documented, but years of experience tells me how
to get it working. :-) I would not be very happy if suddenly all that I know
about how networking works on the desktop is different from my servers.
Hopefully I am missing a key point here.
Tom
11:33 p.m.
On Sun, 2004-08-22 at 23:57 -0400, Tom Diehl wrote:
I am a little confused. Does this mean you would have a different
network
config scheme for desktops as opposed to servers?
No, but you might use the scheme differently for desktop and server and
have aspects of the scheme's design that are most useful in a desktop or
server context. If that makes sense.
I agree it is not well documented, but years of experience tells me
how
to get it working. :-) I would not be very happy if suddenly all that I know
about how networking works on the desktop is different from my servers.
Of course, it's sort of a requirement for desktop that you need not know
how the scheme works ;-)
What NetworkManager does, in essence, is that if you have a wired
ethernet link it dhcp's it, and if you don't it lets you choose a
wireless essid from any that are available, and also specify the
encryption key etc., then dhcp's that. It could be extended to let you
provide a static IP config in a similar way to the wireless info.
If you plug/unplug the network cable then NetworkManager dynamically
moves between wired and wireless. Hopefully I got that right, I'm sure
Dan will correct me if not.
This is obviously nonsense on a server, and the answer is "don't use it
on a server" ;-) You can of course also just configure desktops with
hardwired static IPs in /etc/sysconfig/network-scripts
Havoc
1:56 a.m.
What NetworkManager does, in essence, is that if you have a wired
ethernet link it dhcp's it, and if you don't it lets you choose a
wireless essid from any that are available, and also specify the
encryption key etc., then dhcp's that. It could be extended to let you
provide a static IP config in a similar way to the wireless info.
If you plug/unplug the network cable then NetworkManager dynamically
moves between wired and wireless. Hopefully I got that right, I'm sure
Dan will correct me if not.
This could also be combined with system-config-network or should this really
go in a separate application?
greetings,
Florian La Roche
11:38 a.m.
On Mon, 2004-08-23 at 08:56 +0200, Florian La Roche wrote:
> What NetworkManager does, in essence, is that if you have a
wired
> ethernet link it dhcp's it, and if you don't it lets you choose a
> wireless essid from any that are available, and also specify the
> encryption key etc., then dhcp's that. It could be extended to let you
> provide a static IP config in a similar way to the wireless info.
> If you plug/unplug the network cable then NetworkManager dynamically
> moves between wired and wireless. Hopefully I got that right, I'm sure
> Dan will correct me if not.
This could also be combined with system-config-network or should this really
go in a separate application?
NetworkManager isn't really an application, it's a daemon. The UI for it
is a panel applet and some dialogs rather than something you launch
explicitly.
We do think this is the right UI for the typical desktop case though, s-
c-network should probably tend more in the direction of sysadmin use
cases.
Havoc
1:41 p.m.
Havoc Pennington (hp(a)redhat.com) said:
> This could also be combined with system-config-network or should
this really
> go in a separate application?
NetworkManager isn't really an application, it's a daemon. The UI for it
is a panel applet and some dialogs rather than something you launch
explicitly.
We do think this is the right UI for the typical desktop case though, s-
c-network should probably tend more in the direction of sysadmin use
cases.
But they need to be checked to make sure they play nice with each other;
I'm guessing at this point they're completely ignorant of each other,
and therefore probably don't...
Bill
3:03 a.m.
On Mon, 2004-08-23 at 06:33, Havoc Pennington wrote:
What NetworkManager does, in essence, is that if you have a wired
ethernet link it dhcp's it, and if you don't it lets you choose a
wireless essid from any that are available, and also specify the
encryption key etc., then dhcp's that. It could be extended to let you
provide a static IP config in a similar way to the wireless info.
If you plug/unplug the network cable then NetworkManager dynamically
moves between wired and wireless. Hopefully I got that right, I'm sure
Dan will correct me if not.
Will it have hooks for e.g. configuring network proxies, cups default
destinations, etc. depending on the network/dns domain you're in?
Currently I use a shell script as dhclient's exit hook that does these
things for me (in a more or less reliable manner). Querying for the dns
domain first, then maybe setting a static IP would also be an idea
though I admit it sounds weird ;-).
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
7:30 a.m.
On Mon, 2004-08-23 at 10:03 +0200, Nils Philippsen wrote:
Will it have hooks
I don't think it does at the moment, but it will. We will probably need
hooks for handling VPNs.
for e.g. configuring network proxies,
DHCP provides a means to advertise HTTP proxies, and there are other
ones too. We should make sure we're supporting those instead of
requiring manual configuration.
cups default
destinations,
That's a per-user preference.
7:50 a.m.
On Mon, 2004-08-23 at 08:32 -0400, Alan Cox wrote:
On Mon, Aug 23, 2004 at 08:30:52AM -0400, Colin Walters wrote:
> > cups default
> > destinations,
>
> That's a per-user preference.
Only when the users preferred destination is around. There is service
discovery and UPnP for printers, so it matters for example what office I
am in
We could have eggcups keep a record of say the last 10 printers selected
as default, and they'd be tried in order.
7:57 a.m.
On Mon, 2004-08-23 at 14:50, Colin Walters wrote:
On Mon, 2004-08-23 at 08:32 -0400, Alan Cox wrote:
> On Mon, Aug 23, 2004 at 08:30:52AM -0400, Colin Walters wrote:
> > > cups default
> > > destinations,
> >
> > That's a per-user preference.
>
> Only when the users preferred destination is around. There is service
> discovery and UPnP for printers, so it matters for example what office I
> am in
We could have eggcups keep a record of say the last 10 printers selected
as default, and they'd be tried in order.
or keep context of the network portion of the IP address(es) and
associate printers with those....
7:58 a.m.
On Mon, 2004-08-23 at 14:30, Colin Walters wrote:
On Mon, 2004-08-23 at 10:03 +0200, Nils Philippsen wrote:
> for e.g. configuring network proxies,
DHCP provides a means to advertise HTTP proxies, and there are other
ones too. We should make sure we're supporting those instead of
requiring manual configuration.
There are situations where you don't have an influence on the DHCP
configuration (just being in the network of another company than your
own). Mind I don't talk about fully graphical configuration for that,
just hooks.
> cups default
> destinations,
That's a per-user preference.
Alan answered that already (metoo).
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
8:27 a.m.
On Mon, 2004-08-23 at 14:58 +0200, Nils Philippsen wrote:
On Mon, 2004-08-23 at 14:30, Colin Walters wrote:
> On Mon, 2004-08-23 at 10:03 +0200, Nils Philippsen wrote:
> > for e.g. configuring network proxies,
>
> DHCP provides a means to advertise HTTP proxies, and there are other
> ones too. We should make sure we're supporting those instead of
> requiring manual configuration.
There are situations where you don't have an influence on the DHCP
configuration (just being in the network of another company than your
own). Mind I don't talk about fully graphical configuration for that,
just hooks.
We need to support whatever Windows supports (i.e. what system
administrators are actually deploying), ultimately.
Incidentally, it shouldn't be all that hard to get the http proxy from
DHCP into userspace. dhclient seems to write out the configuration
into /var/lib/dhcp/dhclient-ethX.leases. At worst you could have a
little post-DHCP script that does "grep http-proxy", and then something
like:
dbus-send --system --signal com.redhat.Network.DHCP.HttpProxy string:$(proxy)
Then NetworkManager could listen for this signal and set the GConf key.
Then all applications which use GConf would dynamically pick up the
change.
8:29 a.m.
On Mon, Aug 23, 2004 at 09:27:16AM -0400, Colin Walters wrote:
Incidentally, it shouldn't be all that hard to get the http proxy
from
DHCP into userspace. dhclient seems to write out the configuration
into /var/lib/dhcp/dhclient-ethX.leases. At worst you could have a
little post-DHCP script that does "grep http-proxy", and then something
like:
dbus-send --system --signal com.redhat.Network.DHCP.HttpProxy string:$(proxy)
The dhcp client already runs scripts on various events like network down and
address change. Right now we unfortunately don't do much with that functionality.
Then NetworkManager could listen for this signal and set the GConf
key.
Then all applications which use GConf would dynamically pick up the
change.
Yes
8:39 a.m.
On Mon, 2004-08-23 at 15:27, Colin Walters wrote:
On Mon, 2004-08-23 at 14:58 +0200, Nils Philippsen wrote:
> On Mon, 2004-08-23 at 14:30, Colin Walters wrote:
> > On Mon, 2004-08-23 at 10:03 +0200, Nils Philippsen wrote:
> > > for e.g. configuring network proxies,
> >
> > DHCP provides a means to advertise HTTP proxies, and there are other
> > ones too. We should make sure we're supporting those instead of
> > requiring manual configuration.
>
> There are situations where you don't have an influence on the DHCP
> configuration (just being in the network of another company than your
> own). Mind I don't talk about fully graphical configuration for that,
> just hooks.
We need to support whatever Windows supports (i.e. what system
administrators are actually deploying), ultimately.
Incidentally, it shouldn't be all that hard to get the http proxy from
DHCP into userspace. dhclient seems to write out the configuration
into /var/lib/dhcp/dhclient-ethX.leases. At worst you could have a
little post-DHCP script that does "grep http-proxy", and then something
like:
dbus-send --system --signal com.redhat.Network.DHCP.HttpProxy string:$(proxy)
That sounds good but I'm talking about when the DHCP server doesn't
provide this information. Are when it's inaccurate, e.g. you're at a
customer's site where people login with their Windows accounts to the
proxy which is what DHCP propagates. All external people are expected to
use another proxy.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
9:55 a.m.
On Mon, 2004-08-23 at 15:39 +0200, Nils Philippsen wrote:
That sounds good but I'm talking about when the DHCP server
doesn't
provide this information. Are when it's inaccurate, e.g. you're at a
customer's site where people login with their Windows accounts to the
proxy which is what DHCP propagates. All external people are expected to
use another proxy.
At least here at the Westford office we have a separate area (network)
for external people, so if we had a http proxy that could be given by
the dhcp server for that separate network.
What we really need to solve is better error fallbacks in the web
browser (Epiphany). Instead of popping up a dialog, it should do what
IE does and display an error page. The error page would have links to
the proxy configuration, etc (I think IE does this too). In the proxy
configuration dialog, there could be a checkbox for "Use this proxy for
this network session" or something like that. NetworkManager would then
know to reset the proxy GConf key after the network changes.
2:39 p.m.
On Mon, 2004-08-23 at 17:55, Colin Walters wrote:
On Mon, 2004-08-23 at 15:39 +0200, Nils Philippsen wrote:
> That sounds good but I'm talking about when the DHCP server doesn't
> provide this information. Are when it's inaccurate, e.g. you're at a
> customer's site where people login with their Windows accounts to the
> proxy which is what DHCP propagates. All external people are expected to
> use another proxy.
At least here at the Westford office we have a separate area (network)
for external people, so if we had a http proxy that could be given by
the dhcp server for that separate network.
What we really need to solve is better error fallbacks in the web
browser (Epiphany). Instead of popping up a dialog, it should do what
IE does and display an error page. The error page would have links to
the proxy configuration, etc (I think IE does this too). In the proxy
configuration dialog, there could be a checkbox for "Use this proxy for
this network session" or something like that. NetworkManager would then
know to reset the proxy GConf key after the network changes.
...and with VPN the network session can change underneath the browser.
Would be awfully nice if the browser (and certainly not talking about
Epiphany only here) could be told "switch to this profile" or even just
"reread your proxy configuration" by some means.
- Panu -
2:50 p.m.
On Mon, 2004-08-23 at 22:39 +0300, Panu Matilainen wrote:
...and with VPN the network session can change underneath the
browser.
The browser's hardly unique here, every app that talks to the network
has to be robust in this situation.
Would be awfully nice if the browser (and certainly not talking
about
Epiphany only here) could be told "switch to this profile"
We're trying very hard to avoid profiles, since they introduce a lot of
complexity in the UI.
or even just
"reread your proxy configuration" by some means.
In the ideal case that happens dynamically and transparently, as in the
scenario I posted where the DHCP proxy is propagated via DBus then GConf
to the user session. In the worst case, you get an error loading the
page, and you click on the link on the browser error page.
12:37 a.m.
On Mon, 23 Aug 2004, Colin Walters wrote:
On Mon, 2004-08-23 at 22:39 +0300, Panu Matilainen wrote:
> ...and with VPN the network session can change underneath the browser.
The browser's hardly unique here, every app that talks to the network
has to be robust in this situation.
Sure, the browser is just one of the more user-visible things.
> Would be awfully nice if the browser (and certainly not talking about
> Epiphany only here) could be told "switch to this profile"
We're trying very hard to avoid profiles, since they introduce a lot of
complexity in the UI.
Yep. I wasn't really talking about per-application profiles but something
which the admins can set up beforehand for the user, eg list of settings
(including but not limited to proxies) to switch to when switching between
VPN and "normal" connection.
> or even just
> "reread your proxy configuration" by some means.
In the ideal case that happens dynamically and transparently, as in the
scenario I posted where the DHCP proxy is propagated via DBus then GConf
to the user session. In the worst case, you get an error loading the
page, and you click on the link on the browser error page.
Which is fine for GConf applications but what about all the command line
tools which read proxy config from environment variables which aren't
really changable for the whole session once the user has logged in
(assuming http_proxy and friends are set up in ~/.bash_profile or so)?
- Panu -
5 a.m.
On Tue, 2004-08-24 at 07:37, Panu Matilainen wrote:
Which is fine for GConf applications but what about all the command
line
tools which read proxy config from environment variables which aren't
really changable for the whole session once the user has logged in
(assuming http_proxy and friends are set up in ~/.bash_profile or so)?
I currently have a local proxy (privoxy) which transparently redirects
requests via my squid at home, the local squid if there is no real proxy
available and so on. This works for all apps, GConf or not.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
9:34 p.m.
On Tue, 2004-08-24 at 08:37 +0300, Panu Matilainen wrote:
Yep. I wasn't really talking about per-application profiles but
something
which the admins can set up beforehand for the user, eg list of settings
(including but not limited to proxies) to switch to when switching between
VPN and "normal" connection.
Hmmm. This would probably be possible if we had a little smarts in
GConf.
Which is fine for GConf applications but what about all the command
line
tools which read proxy config from environment variables which aren't
really changable for the whole session once the user has logged in
(assuming http_proxy and friends are set up in ~/.bash_profile or so)?
Fundamentally they're broken, proxy setting needs to be dynamic.
One politically feasible solution might be a little stub library like
"libhttp_proxy" that apps like wget could link to to determine the http
proxy. By default it would just read the environment variable. For
Fedora we'd have this library read out of GConf if available too.
3:15 p.m.
On Mon, 2004-08-23 at 16:55, Colin Walters wrote:
On Mon, 2004-08-23 at 15:39 +0200, Nils Philippsen wrote:
> That sounds good but I'm talking about when the DHCP server doesn't
> provide this information. Are when it's inaccurate, e.g. you're at a
> customer's site where people login with their Windows accounts to the
> proxy which is what DHCP propagates. All external people are expected to
> use another proxy.
At least here at the Westford office we have a separate area (network)
for external people, so if we had a http proxy that could be given by
the dhcp server for that separate network.
This is all fine and dandy and shows that our IS actually knows what it
does. But a "sane" network setup (where sane means easy on our tools ;-)
can't be assumed in every case and is really outside the area of
influence of the exemplar person owning the laptop and by proxy nothing
that can be assumed as operational parameters for our tools. This is
like the situation of web designers who have to keep in mind different
types of browsers, it would be ideal if all would adhere to standards,
but they don't. From my experience, a sane well thought out network is
not the standard unfortunately. To get back to your example, not every
company may have the will, foresight or resources to install a second
LAN just for external people.
What we really need to solve is better error fallbacks in the web
browser (Epiphany). Instead of popping up a dialog, it should do what
IE does and display an error page. The error page would have links to
the proxy configuration, etc (I think IE does this too). In the proxy
configuration dialog, there could be a checkbox for "Use this proxy for
this network session" or something like that. NetworkManager would then
know to reset the proxy GConf key after the network changes.
Actually I think that displaying browser errors in a web page isn't such
a good idea, even if IE does it ;-). Any error detected in the browser
should be distinguishable as such, buttons to reach proxy configuration
are put there as easily as links on a web page.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
4:23 p.m.
On Mon, 2004-08-23 at 22:15 +0200, Nils Philippsen wrote:
To get back to your example, not every
company may have the will, foresight or resources to install a second
LAN just for external people.
Sure. I don't think we can handle every possible case with zero
configuration. But the point is to try very hard to handle as much of
it as possible.
Actually I think that displaying browser errors in a web page
isn't such
a good idea, even if IE does it ;-).
I'm not saying that because IE does it it's a good idea, but rather it
is a good idea that IE happens to do. The error page is a lot less
intrusive than a dialog (even if we fixed the bug where a "host not
found" dialog blocks the entire browser mainloop, it's still nicer to
have an error in the place of origin), and is able to provide a lot more
information.
Any error detected in the browser
should be distinguishable as such,
Why is that?
buttons to reach proxy configuration
are put there as easily as links on a web page.
Sure, but see above.
4:57 a.m.
On Mon, 2004-08-23 at 23:23, Colin Walters wrote:
On Mon, 2004-08-23 at 22:15 +0200, Nils Philippsen wrote:
> To get back to your example, not every
> company may have the will, foresight or resources to install a second
> LAN just for external people.
Sure. I don't think we can handle every possible case with zero
configuration. But the point is to try very hard to handle as much of
it as possible.
Of course, contrary to how my posts may have sounded like I really
appreciate if there are automatisms for these sane, common cases.
> Actually I think that displaying browser errors in a web page
isn't such
> a good idea, even if IE does it ;-).
I'm not saying that because IE does it it's a good idea, but rather it
is a good idea that IE happens to do. The error page is a lot less
intrusive than a dialog (even if we fixed the bug where a "host not
found" dialog blocks the entire browser mainloop, it's still nicer to
have an error in the place of origin), and is able to provide a lot more
information.
See below on why I disagree.
> Any error detected in the browser
> should be distinguishable as such,
Why is that?
Other than the usual power user's whine of me, having it as a web page
may have potential security implications -- if there are holes found in
the browser, we might have people trying to exploit the fact that this
error is displayed as a web page, i.e. phishing, e.g. directing people
to other web pages that look more or less exactly like this, the "please
change your proxy setting" which would of course be a proxy under their
control. Think of current IE or Opera URL line exploits.
In evolution you have to click on a button to verify a PGP signature so
people can't design an HTML mail that only looks like the PGP signature
has been verified. And that is good.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
11:47 a.m.
On Tue, 2004-08-24 at 11:57 +0200, Nils Philippsen wrote:
On Mon, 2004-08-23 at 23:23, Colin Walters wrote:
> On Mon, 2004-08-23 at 22:15 +0200, Nils Philippsen wrote:
>
> > To get back to your example, not every
> > company may have the will, foresight or resources to install a second
> > LAN just for external people.
>
> Sure. I don't think we can handle every possible case with zero
> configuration. But the point is to try very hard to handle as much of
> it as possible.
Of course, contrary to how my posts may have sounded like I really
appreciate if there are automatisms for these sane, common cases.
Well at the very worst, Preferences->Network Proxy is still there. What
it could use is a "Set for this network session only" or something, by
being integrated with NetworkManager.
> > Any error detected in the browser
> > should be distinguishable as such,
>
> Why is that?
Other than the usual power user's whine of me, having it as a web page
may have potential security implications -- if there are holes found in
the browser, we might have people trying to exploit the fact that this
error is displayed as a web page, i.e. phishing, e.g. directing people
to other web pages that look more or less exactly like this, the "please
change your proxy setting" which would of course be a proxy under their
control.
I don't think that the "please change your proxy setting" URL would be
able to change the proxy itself. It would simply launch the proxy
preference dialog. And certainly the browser should be configured so
that the preference dialog can only be launched from its internally-
generated error page.
1:54 a.m.
On Wed, 2004-08-25 at 18:47, Colin Walters wrote:
On Tue, 2004-08-24 at 11:57 +0200, Nils Philippsen wrote:
> On Mon, 2004-08-23 at 23:23, Colin Walters wrote:
> > On Mon, 2004-08-23 at 22:15 +0200, Nils Philippsen wrote:
> >
> > > To get back to your example, not every
> > > company may have the will, foresight or resources to install a second
> > > LAN just for external people.
> >
> > Sure. I don't think we can handle every possible case with zero
> > configuration. But the point is to try very hard to handle as much of
> > it as possible.
>
> Of course, contrary to how my posts may have sounded like I really
> appreciate if there are automatisms for these sane, common cases.
Well at the very worst, Preferences->Network Proxy is still there. What
it could use is a "Set for this network session only" or something, by
being integrated with NetworkManager.
> > > Any error detected in the browser
> > > should be distinguishable as such,
> >
> > Why is that?
>
> Other than the usual power user's whine of me, having it as a web page
> may have potential security implications -- if there are holes found in
> the browser, we might have people trying to exploit the fact that this
> error is displayed as a web page, i.e. phishing, e.g. directing people
> to other web pages that look more or less exactly like this, the "please
> change your proxy setting" which would of course be a proxy under their
> control.
I don't think that the "please change your proxy setting" URL would be
able to change the proxy itself. It would simply launch the proxy
Yes I did think so as well.
preference dialog. And certainly the browser should be configured
so
that the preference dialog can only be launched from its internally-
generated error page.
That when some people are struggling to get the majority of
Windows-ridden persons _not_ to trust everything that's on a web page...
Well the idea is that there will be bugs and there will be security
holes and that I don't want to make it easier for the Black Hats to
exploit these by just popping up a nicely crafted web page. Just think
about the changes you need to do: now you have to check whether
following special links is allowed, therefore you have to remember that
a page is internal... With a dialog you get all of this for free and
trust me, people are not that scared by dialogs than you seem to think
;-).
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
2:39 a.m.
On Thu, 2004-08-26 at 08:54 +0200, Nils Philippsen wrote:
That when some people are struggling to get the majority of
Windows-ridden persons _not_ to trust everything that's on a web page...
Well the idea is that there will be bugs and there will be security
holes and that I don't want to make it easier for the Black Hats to
exploit these by just popping up a nicely crafted web page. Just think
about the changes you need to do: now you have to check whether
following special links is allowed, therefore you have to remember that
a page is internal... With a dialog you get all of this for free and
trust me, people are not that scared by dialogs than you seem to think
;-).
javascript::alert("Phear") will look just like any alert dialog we
create in the system and there are other dialog boxes that can be
constructed via javascript that will be able to trick people in other
interactions.
Actually this is getting worse and worse. Last time I was home using my
mom's PC with IE there was a popup/under window that had what looked to
be a DOS window that just finished a scan of my computer and found some
"bad things". It even had a blinking cursor which I believe was
provided via an animated gif.
Social engineering will always be the best way to spread viruses and
other malicious software. There probably won't be a good way to stop
this anytime soon, if it's ever really possible. Probably the best way
to get around this is for people to be able to reasonably understand and
expect what a computer will do or ask of them at anytime; then they can
always make informed choice with their actions. However since computers
keep changing and updating; the defaults change and things look
different it's pretty hard to expect this of people. This is like being
able to predict what my 4 year old cousin is going to say next, could be
about dinosaurs or it could be about some T.V. show; I can barely
understand what he's saying anyway. Many people feel this way about
computers, "I unplugged the network cable and an Evolution dialog said:
'Error pinging IMAP server' : 'Error: Success'" Next month it will
say
"Error D-BUS activation: failure" :-(
I'm sure clever social engineering has caught us all at one time or
another. When you opened up what seemed like it could be a normal email
and it turned out that the 'Re: Staff Bulletin' subject line which was
just too close to real to ignore is actually spam.
Cheers,
~ Bryan
--
Bryan Clark <bclark(a)redhat.com>
Red Hat Desktop Design Ninja
5:57 a.m.
On Thu, 2004-08-26 at 09:39, Bryan Clark wrote:
On Thu, 2004-08-26 at 08:54 +0200, Nils Philippsen wrote:
> That when some people are struggling to get the majority of
> Windows-ridden persons _not_ to trust everything that's on a web page...
> Well the idea is that there will be bugs and there will be security
> holes and that I don't want to make it easier for the Black Hats to
> exploit these by just popping up a nicely crafted web page. Just think
> about the changes you need to do: now you have to check whether
> following special links is allowed, therefore you have to remember that
> a page is internal... With a dialog you get all of this for free and
> trust me, people are not that scared by dialogs than you seem to think
> ;-).
javascript::alert("Phear") will look just like any alert dialog we
create in the system and there are other dialog boxes that can be
constructed via javascript that will be able to trick people in other
interactions.
Admitted, but then that's a bug in the browsers -- anything originating
from a web page (which by definition is potentially hostile) should be
clearly distinguishable from everything else (e.g. big "JavaScript
Dialog:" prefix in the window title). Other than the web page itself
;-).
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
8:59 p.m.
New subject: UI for Secure Systems (was Re: upgrade to rawhide report)
On Thu, 2004-08-26 at 03:39 -0400, Bryan Clark wrote:
On Thu, 2004-08-26 at 08:54 +0200, Nils Philippsen wrote:
> That when some people are struggling to get the majority of
> Windows-ridden persons _not_ to trust everything that's on a web page...
> Well the idea is that there will be bugs and there will be security
> holes and that I don't want to make it easier for the Black Hats to
> exploit these by just popping up a nicely crafted web page. Just think
> about the changes you need to do: now you have to check whether
> following special links is allowed, therefore you have to remember that
> a page is internal... With a dialog you get all of this for free and
> trust me, people are not that scared by dialogs than you seem to think
> ;-).
javascript::alert("Phear") will look just like any alert dialog we
create in the system and there are other dialog boxes that can be
constructed via javascript that will be able to trick people in other
interactions.
Actually this is getting worse and worse. Last time I was home using my
mom's PC with IE there was a popup/under window that had what looked to
be a DOS window that just finished a scan of my computer and found some
"bad things". It even had a blinking cursor which I believe was
provided via an animated gif.
Social engineering will always be the best way to spread viruses and
other malicious software. There probably won't be a good way to stop
this anytime soon, if it's ever really possible. Probably the best way
to get around this is for people to be able to reasonably understand and
expect what a computer will do or ask of them at anytime; then they can
always make informed choice with their actions. However since computers
keep changing and updating; the defaults change and things look
different it's pretty hard to expect this of people. This is like being
able to predict what my 4 year old cousin is going to say next, could be
about dinosaurs or it could be about some T.V. show; I can barely
understand what he's saying anyway. Many people feel this way about
computers, "I unplugged the network cable and an Evolution dialog said:
'Error pinging IMAP server' : 'Error: Success'" Next month it will
say
"Error D-BUS activation: failure" :-(
Hold on; haven't written that bit yet :-)
There's an interesting paper on these issues here; I'm wondering what
you think of it:
http://www.sims.berkeley.edu/~ping/sid/uidss.pdf
I'm sure clever social engineering has caught us all at one time or
another. When you opened up what seemed like it could be a normal email
and it turned out that the 'Re: Staff Bulletin' subject line which was
just too close to real to ignore is actually spam.
Cheers,
~ Bryan
--
Bryan Clark <bclark(a)redhat.com>
Red Hat Desktop Design Ninja
10:07 a.m.
Will it have hooks for e.g. configuring network proxies, cups
default
destinations, etc. depending on the network/dns domain you're in?
Currently I use a shell script as dhclient's exit hook that does these
things for me (in a more or less reliable manner). Querying for the dns
domain first, then maybe setting a static IP would also be an idea
though I admit it sounds weird ;-).
NetworkManager sends signals over dbus when an interface is
activated/deactivated and when its IP address changes. There is also a
daemon called NetworkManagerDispatcher that sits there, listens for
these signals, and runs any scripts in a particular directory
(currently /etc/NetworkManager.d) with the interface that changed and
its IP address. This has been successfully used to keep VPN sessions
constantly alive no matter which interface you are on, and I imagine it
could be used to do other configuration information.
What people seem to be forgetting here is that NetworkManager is about
_near-zero configuration_. If you have to go around doing out-of-the-
ordinary stuff like disabling network cards explicitly, or keeping two
network cards up at the same time, then you are NOT the use-case for
NetworkManager, and don't use it. Things like proxies and other sorts
of desktop-user configuration in a corporate or home-user situation
should be supported by NM, even if they are not at this time.
Dan
3:39 p.m.
On Mon, 2004-08-23 at 17:07, Dan Williams wrote:
> Will it have hooks for e.g. configuring network proxies, cups
default
> destinations, etc. depending on the network/dns domain you're in?
> Currently I use a shell script as dhclient's exit hook that does these
> things for me (in a more or less reliable manner). Querying for the dns
> domain first, then maybe setting a static IP would also be an idea
> though I admit it sounds weird ;-).
NetworkManager sends signals over dbus when an interface is
activated/deactivated and when its IP address changes. There is also a
daemon called NetworkManagerDispatcher that sits there, listens for
these signals, and runs any scripts in a particular directory
(currently /etc/NetworkManager.d) with the interface that changed and
its IP address. This has been successfully used to keep VPN sessions
constantly alive no matter which interface you are on, and I imagine it
could be used to do other configuration information.
This sounds like "hooks" to me. More or less all I asked for if I
understand this correctly.
What people seem to be forgetting here is that NetworkManager is
about
_near-zero configuration_. If you have to go around doing out-of-the-
ordinary stuff like disabling network cards explicitly, or keeping two
network cards up at the same time, then you are NOT the use-case for
NetworkManager, and don't use it. Things like proxies and other sorts
of desktop-user configuration in a corporate or home-user situation
should be supported by NM, even if they are not at this time.
I personally think that shared infrastructure is good, duplication is
evil. A generic description of NetworkManager, how it sounds to me: "A
daemon that does things automatically depending on the network status",
definitely infrastructure. Of course in its default configuration, with
very limited knowledge about a target network, it can only do these
generic things like doing the DHCP or WLAN dance and surely a limited
setup like one wired plus one wireless at max is a logical first step. I
think that we shouldn't have two separate infrastructures that handle
networking, on the one side "legacy" s-c-network and initscripts and on
the other side NetworkManager where there is a lot of duplication
between them. If I think about it the term "NetworkManager" would be a
bit over the top for something that'd never go beyond this first step.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
3:55 p.m.
On Mon, 23 Aug 2004, Nils Philippsen wrote:
> What people seem to be forgetting here is that NetworkManager is
about
> _near-zero configuration_. If you have to go around doing out-of-the-
> ordinary stuff like disabling network cards explicitly, or keeping two
> network cards up at the same time, then you are NOT the use-case for
> NetworkManager, and don't use it. Things like proxies and other sorts
> of desktop-user configuration in a corporate or home-user situation
> should be supported by NM, even if they are not at this time.
I personally think that shared infrastructure is good, duplication is
evil. A generic description of NetworkManager, how it sounds to me: "A
daemon that does things automatically depending on the network status",
definitely infrastructure. Of course in its default configuration, with
very limited knowledge about a target network, it can only do these
generic things like doing the DHCP or WLAN dance and surely a limited
setup like one wired plus one wireless at max is a logical first step. I
think that we shouldn't have two separate infrastructures that handle
networking, on the one side "legacy" s-c-network and initscripts and on
the other side NetworkManager where there is a lot of duplication
between them. If I think about it the term "NetworkManager" would be a
bit over the top for something that'd never go beyond this first step.
NetworkManager (in Fedora at least) should probably live side-by-side
with s-c-network. We _do_ need somewhere to grab our static IP
information from, and I'm not in the business of writing yet _another_
tool to that stuff. So, in the best world perhaps, you'd use s-c-network
to do most of the config stuff. So, think of this:
1) In Anaconda, during installation, you are asked if you wish to
use "no-hassle/zero-configuration networking". If you say Yes, it adds a
"NETWORK_MANAGER=yes" line in ifcfg-* for all devices. If you say No, it
goes about its normal routine and asks you about each network device and
whether it should get a static IP, etc., but adds "NetworkManager=no" to
the ifcfg-* file instead. (alternatively, turn NetworkManager on for
Workstation/Desktop installs automatically, and off for server installs)
2) NetworkManager then looks for the ifcfg-* files, and if it finds one
for the interface, it greps for a NETWORK_MANAGER=yes line. If it finds
one, it takes over that interface. If it finds a "=no", it ignores the
interface. If it finds no file for that interface, it assumes control of
it (or not, we need to argue that one out).
3) You use s-c-network to switch NetworkManager on/off for any particular
interface, and you also use it to specify static IP addresses, gateways,
and the like. If you choose to use NetworkManager for an interface, you
_cannot_ choose DHCP, you can only choose "Automatic" and "Static IP"
or
soemthing like that.
The point here is that if you chose to use NetworkManager which should
probably be default ofr a "workstation" configuration or something like
that, then you would have to turn NetworkManager _off_ explicitly for any
interface, ie zero user intervention. If you choose a Server config,
NetworkManager would be off by default and you'd have to turn it on
explicitly. But for either case, any configuration that would need to be
done would be done through s-c-network, and hopefully in the
Desktop/Workstation case there would be no need whatsoever to touch
s-c-network at all.
So Yes, there does need to be integration between our config tools and
NetworkManager, and NM needs configuration files of sorts for static IP
addresses and whatnot anyway. Those parts I'm not going to re-invent :)
Dan
5:21 a.m.
On Mon, 2004-08-23 at 17:08 -0400, Colin Walters wrote:
On Mon, 2004-08-23 at 16:55 -0400, Dan Williams wrote:
> 1) In Anaconda, during installation, you are asked if you wish to
> use "no-hassle/zero-configuration networking".
I'd suggest that if you choose DHCP, you get NetworkManager by default.
I suggest that if you use dhcp _and_ profiles, use the following patch:
--- dhclient-script 2004-08-16 21:58:50.000000000 +0100
+++ dhclient-script.new 2004-08-05 00:54:25.000000000 +0100
@@ -83,7 +83,7 @@
[ -f ../network ] && . ../network
[ -f ../networking/network ] && . ../networking/network
-CONFIG=$interface
+CONFIG=`fgrep -il "DEVICE=${interface}" ifcfg-* | cut -f2 -d '-'`
need_config ${CONFIG}
--
Manuel Moreno <manolo(a)miconexion.com>
6:46 a.m.
On Sun, Aug 22, 2004 at 09:37:56PM -0400, Havoc Pennington wrote:
BTW, when using NetworkManager for desktops, do we really need
network-
scripts and sysconfig/networking at all?
Define "desktop". If you mean "dhcp managed disposable splat" then
probably
not, but desktop also covers a large multitude of other things including
secure IPsec networks, static addressing, cable modems, ppp, ...
down to the fact that the configuration is in multiple places:
modprobe.conf, hwconf, network-scripts, sysconfig/networking;
it doesn't seem that well-defined how it all works... maybe I'm just
dense though.
The kernel names interfaces it finds eth0, eth1, ... etc (or ppp0 and so on).
It provides the ability to rename them as you like (so you can rename them
to "ADSL" "DMZ" "DavesRoom" and so on...). The current
process is meant to be
Driver gets loaded
We peer at the MAC
We decide what eth* device it was before from the MAC (optional)
We rename it
We run the scripts
One policy we might try to get closer to: clearly split
autogenerated
information from manually-edited information, and machine-readable
information from human-only information such as scripts.
The how does the user edit it - and don't say "with the config tools" they
are not accessible or complete enough.
Alan
7:45 a.m.
On Mon, 2004-08-23 at 07:46 -0400, Alan Cox wrote:
On Sun, Aug 22, 2004 at 09:37:56PM -0400, Havoc Pennington wrote:
> BTW, when using NetworkManager for desktops, do we really need network-
> scripts and sysconfig/networking at all?
Define "desktop". If you mean "dhcp managed disposable splat" then
probably
not, but desktop also covers a large multitude of other things including
secure IPsec networks,
Yes, for this you definitely need static configuration on the machine.
Handling VPNs is tough, but we need to do it.
static addressing,
If you want to do that, you just don't use NetworkManager.
cable modems,
My experience is these are all just DHCP.
ppp, ...
This is tricky in a NetworkManager world, since there is no way to know
when the user has plugged in a phone cable into their modem (AFAIK).
Probably we will just require using system-config-network for this case.
7:53 a.m.
My experience is these are all just DHCP.
> ppp, ...
This is tricky in a NetworkManager world, since there is no way to know
when the user has plugged in a phone cable into their modem (AFAIK).
Probably we will just require using system-config-network for this case.
this is not just modems. ADSL in europe mostly is ppp
8:08 a.m.
On Mon, Aug 23, 2004 at 08:45:57AM -0400, Colin Walters wrote:
> static addressing,
If you want to do that, you just don't use NetworkManager.
That then requires someone ensures every single script/option/method called
by NetworkManager is also called by the old style paths. It also prevents
numerous sensible real world usages like "dynamic IP on wireless but prefer
my static IP on ethernet when at home" - classic configuration.
> cable modems,
My experience is these are all just DHCP.
Your experience is incomplete.
> ppp, ...
This is tricky in a NetworkManager world, since there is no way to know
when the user has plugged in a phone cable into their modem (AFAIK).
Probably we will just require using system-config-network for this case.
PPP comes over many things - ethernet, atm, isdn, oh yes and modem now and
then. PPPoE termination is common for some sorts of ADSL lines.
Alan
8:28 a.m.
On Mon, 2004-08-23 at 09:08 -0400, Alan Cox wrote:
On Mon, Aug 23, 2004 at 08:45:57AM -0400, Colin Walters wrote:
> > static addressing,
>
> If you want to do that, you just don't use NetworkManager.
That then requires someone ensures every single script/option/method called
by NetworkManager is also called by the old style paths.
Not sure about that. The "old style" is very manual. NetworkManager is
entirely dynamic and moving as much per-user as possible. There are
probably things on the old path that shouldn't be used by
NetworkManager, or if they are used, it should just be as fallbacks.
It also prevents
numerous sensible real world usages like "dynamic IP on wireless but prefer
my static IP on ethernet when at home" - classic configuration.
If you care enough to want a static IP address at home, then it
shouldn't be problematic to set up a DHCP server that has static IPs for
your MACs.
> > cable modems,
>
> My experience is these are all just DHCP.
Your experience is incomplete.
I am well aware of that :)
> > ppp, ...
>
> This is tricky in a NetworkManager world, since there is no way to know
> when the user has plugged in a phone cable into their modem (AFAIK).
> Probably we will just require using system-config-network for this case
8:31 a.m.
On Mon, Aug 23, 2004 at 09:28:49AM -0400, Colin Walters wrote:
> That then requires someone ensures every single
script/option/method called
> by NetworkManager is also called by the old style paths.
Not sure about that. The "old style" is very manual. NetworkManager is
entirely dynamic and moving as much per-user as possible. There are
probably things on the old path that shouldn't be used by
NetworkManager, or if they are used, it should just be as fallbacks.
The alternative is that every application supports both and gets tested with
both. Ughhhhhhhhh.
> It also prevents
> numerous sensible real world usages like "dynamic IP on wireless but prefer
> my static IP on ethernet when at home" - classic configuration.
If you care enough to want a static IP address at home, then it
shouldn't be problematic to set up a DHCP server that has static IPs for
your MACs.
If that is the only machine I posess ?
Don't get me wrong - NetworkManager is potentially a very good thing and can't
tackle all the corner cases at the design stage or in revision 1. I appeciate
that.
Alan
2:24 p.m.
On Mon, 2004-08-23 at 09:31, Alan Cox wrote:
On Mon, Aug 23, 2004 at 09:28:49AM -0400, Colin Walters wrote:
> > That then requires someone ensures every single script/option/method called
> > by NetworkManager is also called by the old style paths.
>
> Not sure about that. The "old style" is very manual. NetworkManager is
> entirely dynamic and moving as much per-user as possible. There are
> probably things on the old path that shouldn't be used by
> NetworkManager, or if they are used, it should just be as fallbacks.
The alternative is that every application supports both and gets tested with
both. Ughhhhhhhhh.
My feeling is that long term a daemon is right for servers too ... the
current style of a nest of shell scripts that tweak system configuration
parameters, run one service or another at one time or another just
isn't coherent or maintainable. It certainly doesn't lend itself to
status monitoring, a config GUI, etc.
For a server though you typically want the operation of the daemon to
be driven off of config files with explicit "reread-config" signals.
But I could see the same daemon being used for both with the dynamic
case being turned on by those config files.
Now, of course, changing the way networking on servers works from what
people are used to is likely to run into just a wee bit of resistance.
Regards,
Owen
11:09 a.m.
On Mon, 2004-08-23 at 09:08 -0400, Alan Cox wrote:
PPP comes over many things - ethernet, atm, isdn, oh yes and modem
now and
then. PPPoE termination is common for some sorts of ADSL lines.
Wow, Evolution complete ate my reply to this. Here's what I said:
Ok. The point isn't PPP so much (which is just a technical detail) as
"what can we autodetect", and thus "what is the UI required". Is
there
any way to know for example that the ADSL router requires a machine to
talk PPP to it? Does it have a DHCP server? etc.
8:31 a.m.
On Mon, 23 Aug 2004 08:45:57 -0400, Colin Walters <walters(a)redhat.com> wrote:
> static addressing,
If you want to do that, you just don't use NetworkManager.
What's the target audience and usage scenario for NetworkManager again?
There are real world intranets that don't use dhcp, where desktops are assigned
a static ip, and where linux, while not officially supported by the
helpdesk or it, is tolerated.
If NetworkManager is there to make connectivity drop-dead easy to
setup and manage, static addressing needs some level of support if you
want to target end-users running systems inside a variety of intranets
and not just home users sitting behind a cable modem router. It's not
so much a question of what a user wants to do... its a question of
what the network-admins force a user to do, and making it as easy and
painless as possible for an end-user trying to get a linux system up
in running in a non-supportive environment.
-jef"sitting on a staticly addresses linux desktop on an intranet at
the moment, and is desperately hoping that the configuration tools get
good enough so that the 10 other people in the wing of the facility
can FINALLY be able to install and configure their own boxes without
ever having to bother me since the hinderdesk doesn't offer ANY
support for linux even though the technical staff are all pretty much
running at least one linux box, but I'm not bitter, not bitter at
all"spaleta
9:06 a.m.
Its planned for NetworkManager to support static IP addresses at some
stage of its development. Just not now.
Dan
On Mon, 2004-08-23 at 09:31 -0400, Jeff Spaleta wrote:
On Mon, 23 Aug 2004 08:45:57 -0400, Colin Walters
<walters(a)redhat.com> wrote:
>> static addressing,
> If you want to do that, you just don't use NetworkManager.
What's the target audience and usage scenario for NetworkManager again?
There are real world intranets that don't use dhcp, where desktops are assigned
a static ip, and where linux, while not officially supported by the
helpdesk or it, is tolerated.
If NetworkManager is there to make connectivity drop-dead easy to
setup and manage, static addressing needs some level of support if you
want to target end-users running systems inside a variety of intranets
and not just home users sitting behind a cable modem router. It's not
so much a question of what a user wants to do... its a question of
what the network-admins force a user to do, and making it as easy and
painless as possible for an end-user trying to get a linux system up
in running in a non-supportive environment.
-jef"sitting on a staticly addresses linux desktop on an intranet at
the moment, and is desperately hoping that the configuration tools get
good enough so that the 10 other people in the wing of the facility
can FINALLY be able to install and configure their own boxes without
ever having to bother me since the hinderdesk doesn't offer ANY
support for linux even though the technical staff are all pretty much
running at least one linux box, but I'm not bitter, not bitter at
all"spaleta
1:44 p.m.
Colin Walters (walters(a)redhat.com) said:
> ppp, ...
This is tricky in a NetworkManager world, since there is no way to know
when the user has plugged in a phone cable into their modem (AFAIK).
Moreover, this is one you really don't want to automatically bring up
unless the user really asks for it.
Bill
9:02 a.m.
On Mon, 2004-08-23 at 07:46 -0400, Alan Cox wrote:
On Sun, Aug 22, 2004 at 09:37:56PM -0400, Havoc Pennington wrote:
> BTW, when using NetworkManager for desktops, do we really need network-
> scripts and sysconfig/networking at all?
Define "desktop". If you mean "dhcp managed disposable splat" then
probably
not, but desktop also covers a large multitude of other things including
secure IPsec networks, static addressing, cable modems, ppp, ...
I'm not trying to say "there are no config files," rather "maybe
there's
no point writing one out if it just says BOOTPROTO=dhcp and nothing
else, as the ones kudzu made for me all currently do - just leave them
blank by default and let NetworkManager decide what to do"
The kernel names interfaces it finds eth0, eth1, ... etc (or ppp0 and
so on).
It provides the ability to rename them as you like (so you can rename them
to "ADSL" "DMZ" "DavesRoom" and so on...). The current
process is meant to be
Driver gets loaded
We peer at the MAC
We decide what eth* device it was before from the MAC (optional)
We rename it
We run the scripts
What's the story on this "wifi0" "sit0" stuff, btw?
> One policy we might try to get closer to: clearly split autogenerated
> information from manually-edited information, and machine-readable
> information from human-only information such as scripts.
The how does the user edit it - and don't say "with the config tools" they
are not accessible or complete enough.
You edit it by changing the manually-edited information. It's the same
idea as the way many config files have a "<include>site-
local.conf</include>" type of statement, where you are supposed to
modify site-local.conf instead of the stock file.
In an ideal system, you might have a file (probably in /var) that
defines the autoprobe results; you have a config file (in /etc) that is
fully machine-readable and defines how to use and/or massage/override
the autoprobe results; from the config file, you point to script hooks
called at well-defined times. The config file should not itself be a
script, because that is not machine-editable.
I don't think we're that far from this now. hwconf is the autoprobe
results for example. kudzu seems to also look at the manual-edited files
though. I guess what I'm saying is have some default behavior as a
function of autoprobe results, and view the manual-edited files as
override of the defaults - then machine-writing defaults into the
manual-edited files isn't necessary.
It's not really a big deal, I'm just wondering how to make things more
robust.
Havoc
10:04 a.m.
On Mon, Aug 23, 2004 at 10:02:12AM -0400, Havoc Pennington wrote:
> We run the scripts
What's the story on this "wifi0" "sit0" stuff, btw?
wifi* is people who do their own thing for some reason. Its an 802.* device
so eth* would have made more sense. sit0 is the 6 in 4 tunnel device.
In an ideal system, you might have a file (probably in /var) that
defines the autoprobe results; you have a config file (in /etc) that is
It can't be in /var because /var can be NFS mounted. Detail only.
I don't think we're that far from this now. hwconf is the
autoprobe
results for example. kudzu seems to also look at the manual-edited files
though. I guess what I'm saying is have some default behavior as a
function of autoprobe results, and view the manual-edited files as
override of the defaults - then machine-writing defaults into the
manual-edited files isn't necessary.
Makes sense.
2:44 p.m.
On Mon, Aug 23, 2004 at 11:04:49AM -0400, Alan Cox wrote:
On Mon, Aug 23, 2004 at 10:02:12AM -0400, Havoc Pennington wrote:
> > We run the scripts
> What's the story on this "wifi0" "sit0" stuff, btw?
wifi* is people who do their own thing for some reason. Its an 802.* device
so eth* would have made more sense. sit0 is the 6 in 4 tunnel device.
wifiX is
typically layer2 stuff which is used with monitor mode to see beacons
etc., and ethX is the one that looks and smells like Ethernet.
Of course then there's wlanX, wlanXsta, wlanXap and athX too :-)
--
Pekka Pietikainen
1:31 p.m.
On Sun, 2004-08-22 at 10:21 -0400, Havoc Pennington wrote:
- X configuration defaults to 800x600 instead of 1024x768, because
the monitor can't be probed. result = fugly; I *thought* older
releases defaulted to 1024, but I could be wrong.
Did you reconfigure X? On a fresh install, we'll default to 800x600,
but I don't know of anything that will change it on an upgrade.
FWIW, the fresh install should be better now with nasrat's changes to
firstboot so you can set your monitor there along with the resolution
and depth.
- the battery applet has the wrong suspend command;
"/usr/bin/apm -s"
- _is_ there a suspend command that works for both
apm and acpi? If not I suggest we add one...
the "echo > /proc/acpi/sleep" thing is just
embarrassing anyway
ACPI sleep is currently embarassing broken in other ways due to the lack
of similar infrastructure to what there is in the APM script. Someone
with sufficient time should be able to make the apmscript generically
usable by both ACPI and APM.
Jeremy
4:11 p.m.
On Mon, 2004-08-23 at 14:31 -0400, Jeremy Katz wrote:
On Sun, 2004-08-22 at 10:21 -0400, Havoc Pennington wrote:
> - X configuration defaults to 800x600 instead of 1024x768, because
> the monitor can't be probed. result = fugly; I *thought* older
> releases defaulted to 1024, but I could be wrong.
Did you reconfigure X? On a fresh install, we'll default to 800x600,
but I don't know of anything that will change it on an upgrade.
I killed hwconf then let kudzu reconfigure, yes.
ACPI sleep is currently embarassing broken in other ways due to the
lack
of similar infrastructure to what there is in the APM script. Someone
with sufficient time should be able to make the apmscript generically
usable by both ACPI and APM.
So basically our current situation is that power management doesn't work
at all? ;-)
Havoc
3:55 a.m.
On Mon, 2004-08-23 at 14:31 -0400, Jeremy Katz wrote:
ACPI sleep is currently embarassing broken in other ways due to the
lack
of similar infrastructure to what there is in the APM script. Someone
with sufficient time should be able to make the apmscript generically
usable by both ACPI and APM.
And PMU :)
--
dwmw2
10:46 p.m.
Havoc Pennington wrote:
Hi,
The standard "list of bugs found on upgrade" mail, I'll file these in
bugzilla in a bit. This was a "yum update" fc2->rawhide, which yum
handled nicely.
- bringing up an interface creates an empty resolv.conf.
Writing a correct resolv.conf results in working network,
so the dhcp succeeds, resolv.conf is just hosed.
This bug bit me on the day this message was recieved.The problem seems
to be resolved now.
Unfortunately, I had no clue as to how to even figure out why I had a
working installation until rebooting the system the next day.
Downloading the latest RPMS on a working system, and then installing the
updates onto the downed network system resolved the problem.
Is this function part of the NetworkManager program?
Jim
11:37 p.m.
On Wed, 2004-08-25 at 23:46 -0400, Jim Cornette wrote:
This bug bit me on the day this message was recieved.The problem
seems
to be resolved now.
Unfortunately, I had no clue as to how to even figure out why I had a
working installation until rebooting the system the next day.
Downloading the latest RPMS on a working system, and then installing the
updates onto the downed network system resolved the problem.
Is this function part of the NetworkManager program?
It was an initscripts bug apparently.
Havoc
7182
days inactive
7187
days old
84 comments
24 participants
participants (24)
-
Alan Cox -
Arjan van de Ven -
Bill Nottingham -
Bryan Clark -
Colin Walters -
Dan Williams -
David Malcolm -
David Woodhouse -
Dax Kelson -
Florian La Roche -
Havoc Pennington -
Jef Spaleta -
Jeremy Katz -
Jim Cornette -
Manuel Moreno -
nathan r. hruby -
Nigel Metheringham -
Nils Philippsen -
Owen Taylor -
Panu Matilainen -
Pekka Pietikäinen -
Peter Arremann -
seth vidal -
Tom Diehl