Re: [RFC PATCH 0/2] Loop device psuedo filesystem
way for the userns (or > >> the host!) to create a new loop-control device owned by that userns > >> and we need to tweak the loop driver to make the created loop devices > >> be owned by the userns. > > > > The patches I posted previously more or less did this using per-ns > > devtmpfs, aside from the ephimeral part. The feedback was "just do it in > > loop," so I sent these to facilitate discussing this option with > > something concrete. I personally still like the per-ns devtmpfs > > approach, but that's been nacked. > The ephemeral part might not be needed using devtmpfs if devtmpfs can > guarantee that the device nodes go away if the device goes away. I > don't know whether it can make that guarantee. > > (a) might be interesting, but I'd expect the same objections to be > > raised as for (c). And it seems to me that (b) is just a alternate > > interface for (a). > True. > >> (Note: I'm deliberately ignoring the fact that just doing this for > >> loop seems to be almost entirely useless right now: you still can't > >> mount the things.) > > You could also argue that it's useless to be able to mount things if you > > have no block device on which to mount them. We have to start somewhere. > True. > But if we take this particular route, then I can imagine a real mess > when someone wants to mount a non-loop device, and we get stuck on how > to expose the device node. Sigh. Then we deal with that horse when we have to make him sing. One way or the other, we're trying to moving forward. > --Andy Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [RFC PATCH 0/2] Loop device psuedo filesystem
ignoring the fact that just doing this for loop seems to be almost entirely useless right now: you still can't mount the things.) You could also argue that it's useless to be able to mount things if you have no block device on which to mount them. We have to start somewhere. True. But if we take this particular route, then I can imagine a real mess when someone wants to mount a non-loop device, and we get stuck on how to expose the device node. Sigh. Then we deal with that horse when we have to make him sing. One way or the other, we're trying to moving forward. --Andy Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device
On Tue, 2014-05-27 at 03:36 +0200, Serge E. Hallyn wrote: > Quoting Michael H. Warfield (m...@wittsend.com): > > On Mon, 2014-05-26 at 11:16 +0200, Seth Forshee wrote: > > > On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA1 > > > > > > > > One question about this patch. > > > > > > > > Why don't you use the devices cgroup check if the root user in that > > > > namespace is allowed to use this device? > > > > > > > > This way you can be sure that the root in that namespace can not access > > > > devices to which the host system did not gave > > > > him access to. > > > > > That might be possible, but I don't want to require something on the > > > host to whitelist the device for the container. Then loop would need to > > > automatically add the device to devices.allow, which doesn't seem > > > desirable to me. But I'm not entirely opposed to the idea if others > > > think this is a better way to go. > > > > I don't see any safe way to avoid it. The host has to be in control of > > what devices can and can not be accessed by the container. > Disagree. loop%d is meaningless until it is attached to a file. So > whether a container can use loop2 vs loop9 is meaningless. The point > of Seth's loopfs as I understood it is that the container simply gets a > unique (not visible to host or any other containers) set of loop devices > which it can attach to files which it owns. So long as the host can't > see the container's loop devices (i.e. so it unwittently mounts it when > looking for a particular UUID for /var), it won't get fooled by them. > So in this case *if* we can do it, a purely namespaced approach - meaning > that we restrict visibility of a particular loopdev to one container - is > perfect. And in that "*if" is a cloud that says "then a miracle occurs" and that miracle needs a lot more detail. How that translates into what is and is not visible and what can be mimiced in a container becomes important (to say nothing of notifying its udev). I think this loopfs thing is the answer for the loop device case, we just need to clear up those details and exorcise the devils we find in them. The loop devices are unique while they strangely seem to work with minimal leakage already (all meta data at this time). Seth remarked that, maybe, he's not paranoid enough. You know that I'm a well trained professional paranoid and I accept if people think I'm overly paranoid (is that even possible?). Even paranoids have enemies and just because you're paranoid it doesn't mean they're not out to get you. While I admit that total isolation is virtually (excuse the pun) impossible that doesn't mean I don't strive to maximize the isolation and analyze the possibilities and consequences of compromise. As I stated, "I don't see any way to avoid it". I would love to be proven wrong. It would permit my life to be so much more easy. But how can we allow this without the host in control of it and directing things to the containers? A container may request something and the host can grant it but the container should not be capable of demanding a device over and above the control of the host. How do we define the rules that say what a container can do and what it cannot do without it involving knowledge in the host (whitelisting as Seth call's it) of what is and is not allowed in the container? We already have the problem that the container devices.allow and devices.deny are major and minor based, which we know is fundamentally flawed in a udev environment. We specify major:minor in the configuration files as if they are cast in cement (which they are in all common cases) but they are not in the general case. Greg K-H hammers on this frequently. The loop devices are unique and deserve a unique solution, I'll agree. But I'm also comfortable that the host should have rules and procedures to whitelist hard devices and loop devices and manage their transfer and/or sharing into the containers. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device
On Mon, 2014-05-26 at 11:16 +0200, Seth Forshee wrote: > On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > One question about this patch. > > > > Why don't you use the devices cgroup check if the root user in that > > namespace is allowed to use this device? > > > > This way you can be sure that the root in that namespace can not access > > devices to which the host system did not gave > > him access to. > That might be possible, but I don't want to require something on the > host to whitelist the device for the container. Then loop would need to > automatically add the device to devices.allow, which doesn't seem > desirable to me. But I'm not entirely opposed to the idea if others > think this is a better way to go. I don't see any safe way to avoid it. The host has to be in control of what devices can and can not be accessed by the container. > Seth Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device
On Mon, 2014-05-26 at 11:16 +0200, Seth Forshee wrote: On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One question about this patch. Why don't you use the devices cgroup check if the root user in that namespace is allowed to use this device? This way you can be sure that the root in that namespace can not access devices to which the host system did not gave him access to. That might be possible, but I don't want to require something on the host to whitelist the device for the container. Then loop would need to automatically add the device to devices.allow, which doesn't seem desirable to me. But I'm not entirely opposed to the idea if others think this is a better way to go. I don't see any safe way to avoid it. The host has to be in control of what devices can and can not be accessed by the container. Seth Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device
On Tue, 2014-05-27 at 03:36 +0200, Serge E. Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Mon, 2014-05-26 at 11:16 +0200, Seth Forshee wrote: On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One question about this patch. Why don't you use the devices cgroup check if the root user in that namespace is allowed to use this device? This way you can be sure that the root in that namespace can not access devices to which the host system did not gave him access to. That might be possible, but I don't want to require something on the host to whitelist the device for the container. Then loop would need to automatically add the device to devices.allow, which doesn't seem desirable to me. But I'm not entirely opposed to the idea if others think this is a better way to go. I don't see any safe way to avoid it. The host has to be in control of what devices can and can not be accessed by the container. Disagree. loop%d is meaningless until it is attached to a file. So whether a container can use loop2 vs loop9 is meaningless. The point of Seth's loopfs as I understood it is that the container simply gets a unique (not visible to host or any other containers) set of loop devices which it can attach to files which it owns. So long as the host can't see the container's loop devices (i.e. so it unwittently mounts it when looking for a particular UUID for /var), it won't get fooled by them. So in this case *if* we can do it, a purely namespaced approach - meaning that we restrict visibility of a particular loopdev to one container - is perfect. And in that *if is a cloud that says then a miracle occurs and that miracle needs a lot more detail. How that translates into what is and is not visible and what can be mimiced in a container becomes important (to say nothing of notifying its udev). I think this loopfs thing is the answer for the loop device case, we just need to clear up those details and exorcise the devils we find in them. The loop devices are unique while they strangely seem to work with minimal leakage already (all meta data at this time). Seth remarked that, maybe, he's not paranoid enough. You know that I'm a well trained professional paranoid and I accept if people think I'm overly paranoid (is that even possible?). Even paranoids have enemies and just because you're paranoid it doesn't mean they're not out to get you. While I admit that total isolation is virtually (excuse the pun) impossible that doesn't mean I don't strive to maximize the isolation and analyze the possibilities and consequences of compromise. As I stated, I don't see any way to avoid it. I would love to be proven wrong. It would permit my life to be so much more easy. But how can we allow this without the host in control of it and directing things to the containers? A container may request something and the host can grant it but the container should not be capable of demanding a device over and above the control of the host. How do we define the rules that say what a container can do and what it cannot do without it involving knowledge in the host (whitelisting as Seth call's it) of what is and is not allowed in the container? We already have the problem that the container devices.allow and devices.deny are major and minor based, which we know is fundamentally flawed in a udev environment. We specify major:minor in the configuration files as if they are cast in cement (which they are in all common cases) but they are not in the general case. Greg K-H hammers on this frequently. The loop devices are unique and deserve a unique solution, I'll agree. But I'm also comfortable that the host should have rules and procedures to whitelist hard devices and loop devices and manage their transfer and/or sharing into the containers. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Mon, 2014-05-19 at 17:04 -0700, Eric W. Biederman wrote: > Seth Forshee writes: > > > What I set out for was feature parity between loop devices in a secure > > container and loop devices on the host. Since some operations currently > > check for system-wide CAP_SYS_ADMIN, the only way I see to accomplish > > this is to push knowledge of the user namespace farther down into the > > driver stack so the check can instead be for CAP_SYS_ADMIN in the user > > namespace associated with the device. > > > > That said, I suspect our current use cases can get by without these > > capabilities. Really though I suspect this is just deferring the > > discussion rather than settling it, and what we'll end up with is little > > more than a fancy way for userspace to ask the kernel to run mknod on > > its behalf. > A fancy way to ask the kernel to run mknod on its behalf is what > /dev/pts is. > When I suggested this I did not mean you should forgo making changes to > allow partitions and the like. What I itended is that you should find a > way to make this safe for users who don't have root capabilities. I like to think in terms of the "rootless" configurations where "root" per se is not absolute and everything is framed in terms of capabilities. > Which possibly means that mount needs to learn how to keep a more > privileged user from using your new loop devices. Not sure I got that one. As user with "more" privileges may or may not have access dependent on the congruence of the privileges. They're not heiarchial. If someone has that "priv" then they have access. If they do not, they do not. > To get to the point where this is really and truly usable I expect to be > technically daunting. Most technically non-trivial problems generally are. > Ultimately the technical challenge is how do we create a block device > that is safe for a user who does not have any capabilities to use, and > what can we do with that block device to make it useful. Concur. It boils down to privilege management and access. Absolutely concur. > Only when the question is can this kernel functionality which is > otherwise safe confuse a preexisting setuid application do namespace > or container bits significantly come into play. Ah... Admittedly it's not as late as our conversation at LinuxPlumbers last year in NOLA but... Maybe late at night but I failed to parse the above. > Eric Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Mon, 2014-05-19 at 17:04 -0700, Eric W. Biederman wrote: Seth Forshee seth.fors...@canonical.com writes: What I set out for was feature parity between loop devices in a secure container and loop devices on the host. Since some operations currently check for system-wide CAP_SYS_ADMIN, the only way I see to accomplish this is to push knowledge of the user namespace farther down into the driver stack so the check can instead be for CAP_SYS_ADMIN in the user namespace associated with the device. That said, I suspect our current use cases can get by without these capabilities. Really though I suspect this is just deferring the discussion rather than settling it, and what we'll end up with is little more than a fancy way for userspace to ask the kernel to run mknod on its behalf. A fancy way to ask the kernel to run mknod on its behalf is what /dev/pts is. When I suggested this I did not mean you should forgo making changes to allow partitions and the like. What I itended is that you should find a way to make this safe for users who don't have root capabilities. I like to think in terms of the rootless configurations where root per se is not absolute and everything is framed in terms of capabilities. Which possibly means that mount needs to learn how to keep a more privileged user from using your new loop devices. Not sure I got that one. As user with more privileges may or may not have access dependent on the congruence of the privileges. They're not heiarchial. If someone has that priv then they have access. If they do not, they do not. To get to the point where this is really and truly usable I expect to be technically daunting. Most technically non-trivial problems generally are. Ultimately the technical challenge is how do we create a block device that is safe for a user who does not have any capabilities to use, and what can we do with that block device to make it useful. Concur. It boils down to privilege management and access. Absolutely concur. Only when the question is can this kernel functionality which is otherwise safe confuse a preexisting setuid application do namespace or container bits significantly come into play. Ah... Admittedly it's not as late as our conversation at LinuxPlumbers last year in NOLA but... Maybe late at night but I failed to parse the above. Eric Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Thu, 2014-05-15 at 21:35 -0700, Greg Kroah-Hartman wrote: > On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote: > > > I think having to pick and choose what device nodes you want in a > > > container is a good thing. Becides, you would have to do the same thing > > > in the kernel anyway, what's wrong with userspace making the decision > > > here, especially as it knows exactly what it wants to do much more so > > > than the kernel ever can. > > > > For 'real' devices that sounds sensible. The thing about loop devices > > is that we simply want to allow a container to say "give me a loop > > device to use" and have it receive a unique loop device (or 3), without > > having to pre-assign them. I think that would be cleaner to do using > > a pseudofs and loop-control device, rather than having to have a > > daemon in userspace on the host farming those out in response to > > some, I don't know, dbus request? > I agree that loop devices would be nice to have in a container, and that > the existing loop interface doesn't really lend itself to that. So > create a new type of thing that acts like a loop device in a container. > But don't try to mess with the whole driver core just for a single type > of device. Yeah, a lot of dynamic devices (like serial devices) can be handled in user space with the proviso that we could use some way to tickle udev and hotplug in the container with events. But the loop device is the real ugly duckling here. It's a unique case of an on-demand device with a shared control device that's not really hot-plug and not really deterministic enough to be handled purely in user space. It presents unique challenges unto itself. Makes sense to me. > greg k-h Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Thu, 2014-05-15 at 21:35 -0700, Greg Kroah-Hartman wrote: On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote: I think having to pick and choose what device nodes you want in a container is a good thing. Becides, you would have to do the same thing in the kernel anyway, what's wrong with userspace making the decision here, especially as it knows exactly what it wants to do much more so than the kernel ever can. For 'real' devices that sounds sensible. The thing about loop devices is that we simply want to allow a container to say give me a loop device to use and have it receive a unique loop device (or 3), without having to pre-assign them. I think that would be cleaner to do using a pseudofs and loop-control device, rather than having to have a daemon in userspace on the host farming those out in response to some, I don't know, dbus request? I agree that loop devices would be nice to have in a container, and that the existing loop interface doesn't really lend itself to that. So create a new type of thing that acts like a loop device in a container. But don't try to mess with the whole driver core just for a single type of device. Yeah, a lot of dynamic devices (like serial devices) can be handled in user space with the proviso that we could use some way to tickle udev and hotplug in the container with events. But the loop device is the real ugly duckling here. It's a unique case of an on-demand device with a shared control device that's not really hot-plug and not really deterministic enough to be handled purely in user space. It presents unique challenges unto itself. Makes sense to me. greg k-h Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] Mount and other notifiers, was: [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Fri, 2014-05-16 at 12:52 -0700, James Bottomley wrote: > On Fri, 2014-05-16 at 15:42 -0400, Michael H. Warfield wrote: > > > As an aside (probably requiring a new thread) we were wondering about > > > some type of notifier on the mount call that we could vector into the > > > host to perform the action. The main issue for us is mount of procfs, > > > which really needs to be a bind mount in a container. All of this led > > > me to speculate that we could use some type of syscall notifier > > > mechanism to manage capabilities in the host and even intercept and > > > complete the syscall action within the host rather than having to keep > > > evolving more an more complex kernel drivers to do this. > > > > Interesting. That could be very useful. That might even help with the > > loop device case where the mounts have to go through loop devices for > > things like file system images and builds. Very interesting... > Right, it might even make the loop case go away because now we can > present a dummy device in the container and when the host sees and > attempted mount on this, it just projects a bind mount into the > container and says I've *wink* mounted your "device" for you. Nice. That idea has prospects. I like the concept. > This idea is extremely rough, it came from a conversation I had with > Pavel (cc'd) just before OpenStack about how we might go about > eliminating our OpenVZ interception of the mount system call which > currently does all of this in kernel, so we have no code and no proof > that it's actually feasible (yet). K. I look forward to hearing more. I switched from OpenVZ years ago to LXC because OpenVZ was falling too far behind in kernel support and patches for the leading edge kernels. At the time, I was working on the MD5 signature code for the Quagga routing suite for BGP and couldn't maintain my hosts with OpenVZ and maintain my BGP connections (I have a public ASN and peer on both IPv4 and IPv6) with MD5 signatures at the same time. At the time LXC had just matured enough to serve my needs. That's interesting to note that OpenVZ did this by intercepting the mount call. Very interesting... > James Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Fri, 2014-05-16 at 12:20 -0700, James Bottomley wrote: > On Thu, 2014-05-15 at 21:42 -0400, Michael H. Warfield wrote: > > On Thu, 2014-05-15 at 15:15 -0700, Greg Kroah-Hartman wrote: > > > > PS - Apparently both parallels and Michael independently > > > > project devices which are hot-plugged on the host into containers. > > > > That also seems like something worth talking about (best practices, > > > > shortcomings, use cases not met by it, any ways tha the kernel can > > > > help out) at ksummit/linuxcon. > > > > > I was told that containers would never want devices hotplugged into > > > them. > > > > Interesting. You were told they (who they?) would never want them? Who > > said that? I would have never thought that given that other > > implementations can provide that. I would certainly want them. Seems > > strange to explicitly relegate LXC containers to being second class > > citizens behind OpenVZ, Parallels, BSD Gaols, and Solaris Zones. > That would probably be me. Running hotplug inside a container is a > security problem and, since containers are easily entered by the host, > it's very easy to listen for the hotplug in the host and inject it into > the container using nsenter. In all virtualization... The host, particularly root on the host, exists as deus ex machina, the "god outside the machine". They are at my mercy. Even hardware virtualization can not protect you from the host. You wanna hear some frightening talks on virtualization, catch Joanna (miss little blue pill) Rutkowska some time. I'm particularly interesting in her takes on the "anti evil-maid attacks" and I sat in on her talks on the "north bridge" and "south bridge" malware evasion techniques. She's a good speaker who makes powerful points that makes you sweat but is pleasant in face to face conversation. I've played with her Qubes distribution a couple of times and the way it works with the TPM to insure a secure boot is interesting. But that's a completely different topic on trusted computing. OTOH, there are plenty of other things to worry about in all forms of virtualization. At Internet Security Systems, where I was a founder, fellow, and "X-Force Senior Wizard", we were looking at the ability to leak information through the USB subsystem. No isolation is perfect, especially when you have USB enabled. But that's my turf. > I don't think the intention is to label anyone's implementation as > preferred. What this shows, I think, is that we all have different > practises when it comes to setting up containers. Some are necessary > because our containers are different. Some could do with serious > examination to see if there's really a best way to do the action which > we would then all use. And I hope to contribute to the discussion of said actions. > > I might believe you were never told they would need them, but that's a > > totally different sense. Are we going to tell RedHat and the Docker > > people that LXC is an inferior technology that is complex and unreliable > > (to quote another poster) compared to these others? They're saying this > > will be enterprise technology. If I go to Amazon AWS or other VPS > > services and compare, are we not going to stand on a level playing > > field? Admittedly, I don't expect Amazon AWS to provide me with serial > > consoles, but I do expect to be able to mount file system images within > > my VPS. > Well, that's another nasty, isn't it. We all have different ways of > coping with mount in the container. I think at plumbers we need to sit > down with some of this plumbing and work out which pipes carry the same > fluids and whether we could unify them. Concur > As an aside (probably requiring a new thread) we were wondering about > some type of notifier on the mount call that we could vector into the > host to perform the action. The main issue for us is mount of procfs, > which really needs to be a bind mount in a container. All of this led > me to speculate that we could use some type of syscall notifier > mechanism to manage capabilities in the host and even intercept and > complete the syscall action within the host rather than having to keep > evolving more an more complex kernel drivers to do this. Interesting. That could be very useful. That might even help with the loop device case where the mounts have to go through loop devices for things like file system images and builds. Very interesting... > James Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Fri, 2014-05-16 at 09:06 -0500, Seth Forshee wrote: > On Thu, May 15, 2014 at 09:35:32PM -0700, Greg Kroah-Hartman wrote: > > On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote: > > > > I think having to pick and choose what device nodes you want in a > > > > container is a good thing. Becides, you would have to do the same thing > > > > in the kernel anyway, what's wrong with userspace making the decision > > > > here, especially as it knows exactly what it wants to do much more so > > > > than the kernel ever can. > > > > > > For 'real' devices that sounds sensible. The thing about loop devices > > > is that we simply want to allow a container to say "give me a loop > > > device to use" and have it receive a unique loop device (or 3), without > > > having to pre-assign them. I think that would be cleaner to do using > > > a pseudofs and loop-control device, rather than having to have a > > > daemon in userspace on the host farming those out in response to > > > some, I don't know, dbus request? > > > > I agree that loop devices would be nice to have in a container, and that > > the existing loop interface doesn't really lend itself to that. So > > create a new type of thing that acts like a loop device in a container. > > But don't try to mess with the whole driver core just for a single type > > of device. > No matter what I don't think we get out of this without driver core > changes, whether this was done in loop or by creating something new. > Not unless the whole thing is punted to userspace, anyway. > The first problem is that many block device ioctls check for > CAP_SYS_ADMIN. Most of these might not ever be used on loop devices, I'm > not really sure. But loop does at minimum support partitions, and to get > that functionality in an unprivileged container at least the block layer > needs to know the namespace which has privileges for that device. Woa! Time out... Sorry, this will be an off topic aside. Loop devices support partitions? I'd love to know how that works. I've tried several times in the past to do that but it's failed every time. I haven't been able to find any how-to in the past. This article was just a couple of years ago (after the last time I tried this): http://madduck.net/blog/2006.10.20:loop-mounting-partitions-from-a-disk-image/ This guy didn't use partitions directly but used the offset to the mount, which is what I had to use. Everything I found always referred to using mount offsets in order to mount partitions within a loop device. Regards, Mike > The second is that all block devices automatically appear in devtmpfs. > The scenario I'm concerned about is that the host could unknowingly use > a loop device exposed to a container, then the container could see data > from the host. So we either need a flag to tell the driver core not to > create a node in devtmpfs, or we need a privileged manager in userspace > to remove them (which kind of defeats the purpose). And it gets more > complicated when partition block devs are mixed in, because they can be > created without involvement from the driver - they would need to inherit > the "no devtmpfs node" property from their parent, and if the driver > uses a psuedo fs to create device nodes for userspace then it needs to > be informed about the partitions too so it can create those nodes. > > So maybe we could get by without the privileged ioctls, as long as it > was understood that unprivileged containers can't do partitioning. But I > do think the devtmpfs problem would need to be addressed. > > Thanks, > Seth > ___ > lxc-devel mailing list > lxc-de...@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel > -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Fri, 2014-05-16 at 09:06 -0500, Seth Forshee wrote: On Thu, May 15, 2014 at 09:35:32PM -0700, Greg Kroah-Hartman wrote: On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote: I think having to pick and choose what device nodes you want in a container is a good thing. Becides, you would have to do the same thing in the kernel anyway, what's wrong with userspace making the decision here, especially as it knows exactly what it wants to do much more so than the kernel ever can. For 'real' devices that sounds sensible. The thing about loop devices is that we simply want to allow a container to say give me a loop device to use and have it receive a unique loop device (or 3), without having to pre-assign them. I think that would be cleaner to do using a pseudofs and loop-control device, rather than having to have a daemon in userspace on the host farming those out in response to some, I don't know, dbus request? I agree that loop devices would be nice to have in a container, and that the existing loop interface doesn't really lend itself to that. So create a new type of thing that acts like a loop device in a container. But don't try to mess with the whole driver core just for a single type of device. No matter what I don't think we get out of this without driver core changes, whether this was done in loop or by creating something new. Not unless the whole thing is punted to userspace, anyway. The first problem is that many block device ioctls check for CAP_SYS_ADMIN. Most of these might not ever be used on loop devices, I'm not really sure. But loop does at minimum support partitions, and to get that functionality in an unprivileged container at least the block layer needs to know the namespace which has privileges for that device. Woa! Time out... Sorry, this will be an off topic aside. Loop devices support partitions? I'd love to know how that works. I've tried several times in the past to do that but it's failed every time. I haven't been able to find any how-to in the past. This article was just a couple of years ago (after the last time I tried this): http://madduck.net/blog/2006.10.20:loop-mounting-partitions-from-a-disk-image/ This guy didn't use partitions directly but used the offset to the mount, which is what I had to use. Everything I found always referred to using mount offsets in order to mount partitions within a loop device. Regards, Mike The second is that all block devices automatically appear in devtmpfs. The scenario I'm concerned about is that the host could unknowingly use a loop device exposed to a container, then the container could see data from the host. So we either need a flag to tell the driver core not to create a node in devtmpfs, or we need a privileged manager in userspace to remove them (which kind of defeats the purpose). And it gets more complicated when partition block devs are mixed in, because they can be created without involvement from the driver - they would need to inherit the no devtmpfs node property from their parent, and if the driver uses a psuedo fs to create device nodes for userspace then it needs to be informed about the partitions too so it can create those nodes. So maybe we could get by without the privileged ioctls, as long as it was understood that unprivileged containers can't do partitioning. But I do think the devtmpfs problem would need to be addressed. Thanks, Seth ___ lxc-devel mailing list lxc-de...@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Fri, 2014-05-16 at 12:20 -0700, James Bottomley wrote: On Thu, 2014-05-15 at 21:42 -0400, Michael H. Warfield wrote: On Thu, 2014-05-15 at 15:15 -0700, Greg Kroah-Hartman wrote: PS - Apparently both parallels and Michael independently project devices which are hot-plugged on the host into containers. That also seems like something worth talking about (best practices, shortcomings, use cases not met by it, any ways tha the kernel can help out) at ksummit/linuxcon. I was told that containers would never want devices hotplugged into them. Interesting. You were told they (who they?) would never want them? Who said that? I would have never thought that given that other implementations can provide that. I would certainly want them. Seems strange to explicitly relegate LXC containers to being second class citizens behind OpenVZ, Parallels, BSD Gaols, and Solaris Zones. That would probably be me. Running hotplug inside a container is a security problem and, since containers are easily entered by the host, it's very easy to listen for the hotplug in the host and inject it into the container using nsenter. In all virtualization... The host, particularly root on the host, exists as deus ex machina, the god outside the machine. They are at my mercy. Even hardware virtualization can not protect you from the host. You wanna hear some frightening talks on virtualization, catch Joanna (miss little blue pill) Rutkowska some time. I'm particularly interesting in her takes on the anti evil-maid attacks and I sat in on her talks on the north bridge and south bridge malware evasion techniques. She's a good speaker who makes powerful points that makes you sweat but is pleasant in face to face conversation. I've played with her Qubes distribution a couple of times and the way it works with the TPM to insure a secure boot is interesting. But that's a completely different topic on trusted computing. OTOH, there are plenty of other things to worry about in all forms of virtualization. At Internet Security Systems, where I was a founder, fellow, and X-Force Senior Wizard, we were looking at the ability to leak information through the USB subsystem. No isolation is perfect, especially when you have USB enabled. But that's my turf. I don't think the intention is to label anyone's implementation as preferred. What this shows, I think, is that we all have different practises when it comes to setting up containers. Some are necessary because our containers are different. Some could do with serious examination to see if there's really a best way to do the action which we would then all use. And I hope to contribute to the discussion of said actions. I might believe you were never told they would need them, but that's a totally different sense. Are we going to tell RedHat and the Docker people that LXC is an inferior technology that is complex and unreliable (to quote another poster) compared to these others? They're saying this will be enterprise technology. If I go to Amazon AWS or other VPS services and compare, are we not going to stand on a level playing field? Admittedly, I don't expect Amazon AWS to provide me with serial consoles, but I do expect to be able to mount file system images within my VPS. Well, that's another nasty, isn't it. We all have different ways of coping with mount in the container. I think at plumbers we need to sit down with some of this plumbing and work out which pipes carry the same fluids and whether we could unify them. Concur As an aside (probably requiring a new thread) we were wondering about some type of notifier on the mount call that we could vector into the host to perform the action. The main issue for us is mount of procfs, which really needs to be a bind mount in a container. All of this led me to speculate that we could use some type of syscall notifier mechanism to manage capabilities in the host and even intercept and complete the syscall action within the host rather than having to keep evolving more an more complex kernel drivers to do this. Interesting. That could be very useful. That might even help with the loop device case where the mounts have to go through loop devices for things like file system images and builds. Very interesting... James Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] Mount and other notifiers, was: [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Fri, 2014-05-16 at 12:52 -0700, James Bottomley wrote: On Fri, 2014-05-16 at 15:42 -0400, Michael H. Warfield wrote: As an aside (probably requiring a new thread) we were wondering about some type of notifier on the mount call that we could vector into the host to perform the action. The main issue for us is mount of procfs, which really needs to be a bind mount in a container. All of this led me to speculate that we could use some type of syscall notifier mechanism to manage capabilities in the host and even intercept and complete the syscall action within the host rather than having to keep evolving more an more complex kernel drivers to do this. Interesting. That could be very useful. That might even help with the loop device case where the mounts have to go through loop devices for things like file system images and builds. Very interesting... Right, it might even make the loop case go away because now we can present a dummy device in the container and when the host sees and attempted mount on this, it just projects a bind mount into the container and says I've *wink* mounted your device for you. Nice. That idea has prospects. I like the concept. This idea is extremely rough, it came from a conversation I had with Pavel (cc'd) just before OpenStack about how we might go about eliminating our OpenVZ interception of the mount system call which currently does all of this in kernel, so we have no code and no proof that it's actually feasible (yet). K. I look forward to hearing more. I switched from OpenVZ years ago to LXC because OpenVZ was falling too far behind in kernel support and patches for the leading edge kernels. At the time, I was working on the MD5 signature code for the Quagga routing suite for BGP and couldn't maintain my hosts with OpenVZ and maintain my BGP connections (I have a public ASN and peer on both IPv4 and IPv6) with MD5 signatures at the same time. At the time LXC had just matured enough to serve my needs. That's interesting to note that OpenVZ did this by intercepting the mount call. Very interesting... James Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
; That also seems like something worth talking about (best practices, > > shortcomings, use cases not met by it, any ways tha the kernel can > > help out) at ksummit/linuxcon. > I was told that containers would never want devices hotplugged into > them. Interesting. You were told they (who they?) would never want them? Who said that? I would have never thought that given that other implementations can provide that. I would certainly want them. Seems strange to explicitly relegate LXC containers to being second class citizens behind OpenVZ, Parallels, BSD Gaols, and Solaris Zones. I might believe you were never told they would need them, but that's a totally different sense. Are we going to tell RedHat and the Docker people that LXC is an inferior technology that is complex and unreliable (to quote another poster) compared to these others? They're saying this will be enterprise technology. If I go to Amazon AWS or other VPS services and compare, are we not going to stand on a level playing field? Admittedly, I don't expect Amazon AWS to provide me with serial consoles, but I do expect to be able to mount file system images within my VPS. > What use case has this happening / needed? Hello? Dink... Dink... Is this microphone on? I've already detailed out a use case (serial USB console case) that I'm dealing with now. Now, I'm dealing with it in host user space and that's probably the correct answer there. I probably don't need kernel space help in this particular case. There's still a lot of bolt holes to fill with bolts though for the more general case. It's not the common case but it is a valid legitimate use case and one that would be expected of a "virtual machine" (VirtualBox can handle it - waste of computing cycles that it is). The loopback device case is even more common and, currently, rather inconsistent but strangle self consistent and workable. In the 80/20 case, I agree we can and should deal with this in the host user space as much as possible. That's the realm I'm working within. Seth and others seem to want more in the namespace region and I'm not convinced. But, I'm not convinced we can accomplish everything in user space either. We've got use cases and we've got problem sets. Don't give into confirmational bias and automatically discount the use cases that have been mentioned and then assume there are none. I don't know if Seth's paths are part of the answer or not. I'm not pro Seth's patches or against Seth's patches but we've got a need in search of solutions. > thanks, > greg k-h Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Wed, 2014-05-14 at 21:00 -0700, Greg Kroah-Hartman wrote: > On Wed, May 14, 2014 at 10:15:27PM -0500, Seth Forshee wrote: > > On Wed, May 14, 2014 at 10:17:31PM -0400, Michael H. Warfield wrote: > > > > > Using devtmpfs is one possible > > > > > solution, and it would have the added benefit of making container > > > > > setup > > > > > simpler. But simply letting containers mount devtmpfs isn't sufficient > > > > > since the container may need to see a different, more limited set of > > > > > devices, and because different environments making modifications to > > > > > the filesystem could lead to conflicts. > > > > > > > > > > This series solves these problems by assigning devices to user > > > > > namespaces. Each device has an "owner" namespace which specifies which > > > > > devtmpfs mount the device should appear in as well allowing priveleged > > > > > operations on the device from that namespace. This defaults to > > > > > init_user_ns. There's also an ns_global flag to indicate a device > > > > > should > > > > > appear in all devtmpfs mounts. > > > > > > > I'd strongly argue that this isn't even a "problem" at all. And, as I > > > > said at the Plumbers conference last year, adding namespaces to devices > > > > isn't going to happen, sorry. Please don't continue down this path. > > > > > > I was just mentioning that to Serge just a week or so ago reminding him > > > of what you told all of us face to face back then. We were having a > > > discussion over loop devices into containers and this topic came up. > > > > It was the loop device use case that got me started down this path in > > the first place, so I don't personally have any interest in physical > > devices right now (though I was sure others would). > Why do you want to give access to a loop device to a container? > Shouldn't you set up the loop devices before creating the container and > then pass those mount points into the container? I thought that was how > things worked today, or am I missing something? Ah, you keep feeding me easy ones. I need raw access to loop devices and loop-control because I'm using containers to build NST (Network Security Toolkit) distribution iso images (one container is x86_64 while the other is i686). Each requires 2 loop devices. You can't set up the loop devices in advance since the containers will be creating the images and building them. NST tinkers with the base build engine configuration, so I really DON'T want it running on a hard iron host. There may be other cases where I need other specialized containers for building distros. I'm also looking at custom builds of Kali (another security distribution). > Giving the ability for a container to create a loop device at all is a > horrid idea, as you have pointed out, lots of information leakage could > easily happen. It does but only slightly. I noticed that losetup will list all the devices regardless of container where run or the container where set up. But that seems to be largely cosmetic. You can't do anything with the loop device in the other container. You can't disconnected it, read it, or mount it (I've tested it). In the former case, losetup returns with no error but does nothing. In the later case, you get a busy error. Not clean, not pretty, but no damage. Since loop-control is working on the global pool of loop devices, it's impossible to know what device to move to what container when the container runs losetup. For me, this isn't a serious problem, since it only involves 2 specialized containers out of over 4 dozen containers I have running across 3 sites. And those two containers are under my explicit and exclusive control. None of the others need it. I can get away with adding extra loop devices and adding them to the containers and let losetup deal with allocation and contention. Serge mentioned something to me about a loopdevfs (?) thing that someone else is working on. That would seem to be a better solution in this particular case but I don't know much about it or where it's at. Mind you, I heard your arguments at LinuxPlumbers regarding pushing user space policies into the kernel and all and basically I agree with you, this should be handled in host system user space and it seems reasonable. I'm just pointing out real world cases I have in operation right now and pointing out that I have solutions for them in host user space, even if some of them may not be estheticly pretty. > greg k-h Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Wed, 2014-05-14 at 21:00 -0700, Greg Kroah-Hartman wrote: On Wed, May 14, 2014 at 10:15:27PM -0500, Seth Forshee wrote: On Wed, May 14, 2014 at 10:17:31PM -0400, Michael H. Warfield wrote: Using devtmpfs is one possible solution, and it would have the added benefit of making container setup simpler. But simply letting containers mount devtmpfs isn't sufficient since the container may need to see a different, more limited set of devices, and because different environments making modifications to the filesystem could lead to conflicts. This series solves these problems by assigning devices to user namespaces. Each device has an owner namespace which specifies which devtmpfs mount the device should appear in as well allowing priveleged operations on the device from that namespace. This defaults to init_user_ns. There's also an ns_global flag to indicate a device should appear in all devtmpfs mounts. I'd strongly argue that this isn't even a problem at all. And, as I said at the Plumbers conference last year, adding namespaces to devices isn't going to happen, sorry. Please don't continue down this path. I was just mentioning that to Serge just a week or so ago reminding him of what you told all of us face to face back then. We were having a discussion over loop devices into containers and this topic came up. It was the loop device use case that got me started down this path in the first place, so I don't personally have any interest in physical devices right now (though I was sure others would). Why do you want to give access to a loop device to a container? Shouldn't you set up the loop devices before creating the container and then pass those mount points into the container? I thought that was how things worked today, or am I missing something? Ah, you keep feeding me easy ones. I need raw access to loop devices and loop-control because I'm using containers to build NST (Network Security Toolkit) distribution iso images (one container is x86_64 while the other is i686). Each requires 2 loop devices. You can't set up the loop devices in advance since the containers will be creating the images and building them. NST tinkers with the base build engine configuration, so I really DON'T want it running on a hard iron host. There may be other cases where I need other specialized containers for building distros. I'm also looking at custom builds of Kali (another security distribution). Giving the ability for a container to create a loop device at all is a horrid idea, as you have pointed out, lots of information leakage could easily happen. It does but only slightly. I noticed that losetup will list all the devices regardless of container where run or the container where set up. But that seems to be largely cosmetic. You can't do anything with the loop device in the other container. You can't disconnected it, read it, or mount it (I've tested it). In the former case, losetup returns with no error but does nothing. In the later case, you get a busy error. Not clean, not pretty, but no damage. Since loop-control is working on the global pool of loop devices, it's impossible to know what device to move to what container when the container runs losetup. For me, this isn't a serious problem, since it only involves 2 specialized containers out of over 4 dozen containers I have running across 3 sites. And those two containers are under my explicit and exclusive control. None of the others need it. I can get away with adding extra loop devices and adding them to the containers and let losetup deal with allocation and contention. Serge mentioned something to me about a loopdevfs (?) thing that someone else is working on. That would seem to be a better solution in this particular case but I don't know much about it or where it's at. Mind you, I heard your arguments at LinuxPlumbers regarding pushing user space policies into the kernel and all and basically I agree with you, this should be handled in host system user space and it seems reasonable. I'm just pointing out real world cases I have in operation right now and pointing out that I have solutions for them in host user space, even if some of them may not be estheticly pretty. greg k-h Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
certainly want them. Seems strange to explicitly relegate LXC containers to being second class citizens behind OpenVZ, Parallels, BSD Gaols, and Solaris Zones. I might believe you were never told they would need them, but that's a totally different sense. Are we going to tell RedHat and the Docker people that LXC is an inferior technology that is complex and unreliable (to quote another poster) compared to these others? They're saying this will be enterprise technology. If I go to Amazon AWS or other VPS services and compare, are we not going to stand on a level playing field? Admittedly, I don't expect Amazon AWS to provide me with serial consoles, but I do expect to be able to mount file system images within my VPS. What use case has this happening / needed? Hello? Dink... Dink... Is this microphone on? I've already detailed out a use case (serial USB console case) that I'm dealing with now. Now, I'm dealing with it in host user space and that's probably the correct answer there. I probably don't need kernel space help in this particular case. There's still a lot of bolt holes to fill with bolts though for the more general case. It's not the common case but it is a valid legitimate use case and one that would be expected of a virtual machine (VirtualBox can handle it - waste of computing cycles that it is). The loopback device case is even more common and, currently, rather inconsistent but strangle self consistent and workable. In the 80/20 case, I agree we can and should deal with this in the host user space as much as possible. That's the realm I'm working within. Seth and others seem to want more in the namespace region and I'm not convinced. But, I'm not convinced we can accomplish everything in user space either. We've got use cases and we've got problem sets. Don't give into confirmational bias and automatically discount the use cases that have been mentioned and then assume there are none. I don't know if Seth's paths are part of the answer or not. I'm not pro Seth's patches or against Seth's patches but we've got a need in search of solutions. thanks, greg k-h Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Wed, 2014-05-14 at 18:32 -0700, Greg Kroah-Hartman wrote:
> On Wed, May 14, 2014 at 04:34:48PM -0500, Seth Forshee wrote:
> > Unpriveleged containers cannot run mknod, making it difficult to support
> > devices which appear at runtime.
> Wait.
> Why would you even want a container to see a "new" device? That's the
> whole point, your container should see a "clean" system, not the "this
> USB device was just plugged in" system. Otherwise, how are you going to
> even tell that container a new device showed up? Are you now going to
> add udev support in containers? Hah, no.
Oooo... I can answer that... Tell me if you've heard this one
before... (You have back in NOLA last summer)...
I use a USB sharing device that controls a multiport USB serial device
controlling serial consoles to 16 servers and shared between 4
controlling servers. The sharing control port (a USB HID device) should
be shared between designated containers so that any designated container
owner can "request" a console to one of the other servers (yeah, I know
there can be contention but that's the way the cookie crumbles - most of
the time it's on the master host). Once they get the sharing device's
attention, they "lose" that HID control device (it disappears from /dev
entirely) and they gain only their designated USBtty{n} device for their
console. Dynamic devices at their finest.
I worked out a way of dealing with it using udev rules in the host and
shifting devices using subdirectories in /dev. I got the infrastructure
implemented but didn't finish the specific udev rules.
> > Using devtmpfs is one possible
> > solution, and it would have the added benefit of making container setup
> > simpler. But simply letting containers mount devtmpfs isn't sufficient
> > since the container may need to see a different, more limited set of
> > devices, and because different environments making modifications to
> > the filesystem could lead to conflicts.
> >
> > This series solves these problems by assigning devices to user
> > namespaces. Each device has an "owner" namespace which specifies which
> > devtmpfs mount the device should appear in as well allowing priveleged
> > operations on the device from that namespace. This defaults to
> > init_user_ns. There's also an ns_global flag to indicate a device should
> > appear in all devtmpfs mounts.
> I'd strongly argue that this isn't even a "problem" at all. And, as I
> said at the Plumbers conference last year, adding namespaces to devices
> isn't going to happen, sorry. Please don't continue down this path.
I was just mentioning that to Serge just a week or so ago reminding him
of what you told all of us face to face back then. We were having a
discussion over loop devices into containers and this topic came up.
> greg k-h
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Wed, 2014-05-14 at 18:32 -0700, Greg Kroah-Hartman wrote:
On Wed, May 14, 2014 at 04:34:48PM -0500, Seth Forshee wrote:
Unpriveleged containers cannot run mknod, making it difficult to support
devices which appear at runtime.
Wait.
Why would you even want a container to see a new device? That's the
whole point, your container should see a clean system, not the this
USB device was just plugged in system. Otherwise, how are you going to
even tell that container a new device showed up? Are you now going to
add udev support in containers? Hah, no.
Oooo... I can answer that... Tell me if you've heard this one
before... (You have back in NOLA last summer)...
I use a USB sharing device that controls a multiport USB serial device
controlling serial consoles to 16 servers and shared between 4
controlling servers. The sharing control port (a USB HID device) should
be shared between designated containers so that any designated container
owner can request a console to one of the other servers (yeah, I know
there can be contention but that's the way the cookie crumbles - most of
the time it's on the master host). Once they get the sharing device's
attention, they lose that HID control device (it disappears from /dev
entirely) and they gain only their designated USBtty{n} device for their
console. Dynamic devices at their finest.
I worked out a way of dealing with it using udev rules in the host and
shifting devices using subdirectories in /dev. I got the infrastructure
implemented but didn't finish the specific udev rules.
Using devtmpfs is one possible
solution, and it would have the added benefit of making container setup
simpler. But simply letting containers mount devtmpfs isn't sufficient
since the container may need to see a different, more limited set of
devices, and because different environments making modifications to
the filesystem could lead to conflicts.
This series solves these problems by assigning devices to user
namespaces. Each device has an owner namespace which specifies which
devtmpfs mount the device should appear in as well allowing priveleged
operations on the device from that namespace. This defaults to
init_user_ns. There's also an ns_global flag to indicate a device should
appear in all devtmpfs mounts.
I'd strongly argue that this isn't even a problem at all. And, as I
said at the Plumbers conference last year, adding namespaces to devices
isn't going to happen, sorry. Please don't continue down this path.
I was just mentioning that to Serge just a week or so ago reminding him
of what you told all of us face to face back then. We were having a
discussion over loop devices into containers and this topic came up.
greg k-h
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
Re: 2.6.24: Serial disabled in BIOS but serial modules still loaded (probably PnP related)
On Sat, 2007-11-24 at 23:36 +0300, Andrey Borzenkov wrote: > I have no COM port on notebook (without port replicator which I do not have) > so COM is disabled in BIOS. No ttyS* is detected during boot (and no device > created) but I just noticed that serial modules are still loaded. Well, this > partially defeats the purpose of disabling COM port - the intention was to > free resources by *not* loading unneeded modules ... > This may have something to do with (ACPI) PnP which apparently believes COM > is alive. > Notebook is Toshiba Portege 4000. Nice... What's this then? > 00:09 PNP0501 16550A-compatible serial port > state = active > io 0x3f8-0x3ff > irq 5 0x3f8-0x3ff is COM1 and a 16550A is the most common invocation of the vernerable serial port. I haven't seen a real 8250 in ages. the 16550 is an 8250 with larger FIFO's and better rates. Now, it's on IRQ5 instead of IRQ4 but that's all allocatable on PCI. Unless I'm missing something, it looks like you've got a COM port and it looks like it's active. Might be related to an IR port? > 00:0a SMCf010 SMC Fast Infrared Port > state = disabled > 00:0b PNP0401 ECP printer port > state = disabled : Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | [EMAIL PROTECTED] /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: 2.6.24: Serial disabled in BIOS but serial modules still loaded (probably PnP related)
On Sat, 2007-11-24 at 23:36 +0300, Andrey Borzenkov wrote: I have no COM port on notebook (without port replicator which I do not have) so COM is disabled in BIOS. No ttyS* is detected during boot (and no device created) but I just noticed that serial modules are still loaded. Well, this partially defeats the purpose of disabling COM port - the intention was to free resources by *not* loading unneeded modules ... This may have something to do with (ACPI) PnP which apparently believes COM is alive. Notebook is Toshiba Portege 4000. Nice... What's this then? 00:09 PNP0501 16550A-compatible serial port state = active io 0x3f8-0x3ff irq 5 0x3f8-0x3ff is COM1 and a 16550A is the most common invocation of the vernerable serial port. I haven't seen a real 8250 in ages. the 16550 is an 8250 with larger FIFO's and better rates. Now, it's on IRQ5 instead of IRQ4 but that's all allocatable on PCI. Unless I'm missing something, it looks like you've got a COM port and it looks like it's active. Might be related to an IR port? 00:0a SMCf010 SMC Fast Infrared Port state = disabled 00:0b PNP0401 ECP printer port state = disabled : Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | [EMAIL PROTECTED] /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [2.6 patch] remove obsolete Computone MAINTAINERS entry (fwd)
On Sat, Jan 01, 2005 at 06:28:32PM +0100, Adrian Bunk wrote: > At least the mailing list is definitely dead: The mailing list use to be run by Louis Zamora who use to work for Computone. Guess I need to deal with that and move it to some of my own hardware. I hadn't realized it was out of commission. > <[EMAIL PROTECTED]>: > Sorry, I wasn't able to establish an SMTP connection. (#4.4.1) > I'm not going to try again; this message has been in the queue too long. > > I've got two patches in my queue for the Computone drivers for > > 2.6 plus three patches that apply to both the 2.4 and 2.6 kernels. I've > > got to check to see if Marcelo got around to integrating those patches > > into 2.4 and then jump onto the combined patches. > > As Shrek said... (You didn't slay the dragon?) - "It's on my > > todo list". > It seems you are still active :-) , so why is it "Orphaned"? Good question. Probably someone jumping the gun a bit because I haven't been very active on that driver lately. I do tend to drop off the radar for months at a time, depending on other projects and engagements. I haven't done updates to the driver in the 2.6 kernel and, yes, it is broken. Marcelo integrated my 2.4 patches and I've got testers running that code now. I've got a 2.6 patch that integrates those fixes and fixes some 2.6 problems. In the course of working on the 2.6 patch I stumbled onto another problem that had to be retrofitted back into the 2.4 patch which, fortunately, made it into the patch I gave to Marcelo. I'm looking over a couple of other changes that went in with that 2.4 update. I'll try and get a patch out in a couple of days against 2.6.10. > > Mike > cu > Adrian > -- >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! pgpB84aQc0l58.pgp Description: PGP signature
Re: [2.6 patch] remove obsolete Computone MAINTAINERS entry (fwd)
On Sat, Jan 01, 2005 at 06:28:32PM +0100, Adrian Bunk wrote: At least the mailing list is definitely dead: The mailing list use to be run by Louis Zamora who use to work for Computone. Guess I need to deal with that and move it to some of my own hardware. I hadn't realized it was out of commission. [EMAIL PROTECTED]: Sorry, I wasn't able to establish an SMTP connection. (#4.4.1) I'm not going to try again; this message has been in the queue too long. I've got two patches in my queue for the Computone drivers for 2.6 plus three patches that apply to both the 2.4 and 2.6 kernels. I've got to check to see if Marcelo got around to integrating those patches into 2.4 and then jump onto the combined patches. As Shrek said... (You didn't slay the dragon?) - It's on my todo list. It seems you are still active :-) , so why is it Orphaned? Good question. Probably someone jumping the gun a bit because I haven't been very active on that driver lately. I do tend to drop off the radar for months at a time, depending on other projects and engagements. I haven't done updates to the driver in the 2.6 kernel and, yes, it is broken. Marcelo integrated my 2.4 patches and I've got testers running that code now. I've got a 2.6 patch that integrates those fixes and fixes some 2.6 problems. In the course of working on the 2.6 patch I stumbled onto another problem that had to be retrofitted back into the 2.4 patch which, fortunately, made it into the patch I gave to Marcelo. I'm looking over a couple of other changes that went in with that 2.4 update. I'll try and get a patch out in a couple of days against 2.6.10. Mike cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! pgpB84aQc0l58.pgp Description: PGP signature
Re: [PATCH] catch potential null derefs in drivers/char/ip2main.c (245ac16)
>(box+i*ABS_MAX_BOXES)); > + } > + } > } > - } > } > #endif > > -- > Regards, > Rasmus([EMAIL PROTECTED]) > > A chicken and an egg are lying in bed. The chicken is smoking a > cigarette with a satisfied smile on it's face and the egg is frowning > and looking a bit pissed off. The egg mutters, to no-one in particular, > "Well, I guess we answered THAT question..." -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] catch potential null derefs in drivers/char/ip2main.c (245ac16)
is frowning and looking a bit pissed off. The egg mutters, to no-one in particular, Well, I guess we answered THAT question... -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Fri, Jun 08, 2001 at 01:33:44PM -0800, Leif Sawyer wrote: > > From: L. K. [mailto:[EMAIL PROTECTED]] > > I really do not belive that for a CPU or a motherboard +- 1 > > degree would make any difference. > You haven't pushed your system, or run it in a hostile > environment then. There are many places where systems are run > right up to the edge of thermal breakdown, and it's a firm > requirement to know exactly what that edge is. > > If a CPU runs fine at, say, 37 degrees C, I do not belive it > > will have any problems running at 38 or 36 degrees. I support > > the ideea of having very good sensors for temperature > > monitoring, but CPU and motherboard temperature do not depend > > on the rise of the temperature of 1 degree, but when the > > temperature rises 10 or more degrees. I hope you understand > > what I want to say. > I have a CPU that runs great up to 43C, and shuts down hard at 44C > so I obviously want to know how close I am to that. I don't want > rounding errors to get in the way, and I don't want changes > between kernel revs to affect it either. If the rounding errors are less than the accuracy and the reproducibility of your sensor, and you operate in that range and depend on those values, then you have no clue where you are, no matter what your granularity. You sound like the classic example of why we should NOT do this. You are foolish enough to depend on that precision and think that it's accuracy and think that it means something in comparision to the identical measurement 15 minutes later. It does not. > If we've got the bitspace, keep the counters as granular as > possible within the useable range that we're designing for. > counter = .01 * degrees kelvin Then you are being foolish. Your sensors are neither accurate to that degree nor are they reproducible to that degree. What you are describing is jibberish. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote: > The bits are free; the API is hard to change. > Sensors might get better, at least on high-end systems. > Rounding gives a constant 0.15 degree error. > Only the truly stupid would assume accuracy from decimal places. > Again, the bits are free; the API is hard to change. Twice a year I'm a judge at science fairs. Once at the local level and once at the state level. I generally judge on the senior level in the physics category. All too often I have a hard time even convincing some of my fellow judges. Each year there is at least one project where some student has used "fancy scientific equipment" to make measurements of impressive precision and beautiful results. Till you look closer and you find that their standard deviation is as large as their averages and their raw test results are all over the map. With 5 or more decimal places of precision, you find that their sample sizes and proceedures don't even support one or two decimal places, if they are lucky. If it were not for the fact that I don't think they are really that good at it, I would give them an award for "if you can't dazzle them with brilliance, baffle them with bullshit". Unfortunately, they honestly don't KNOW the difference between precision and accuracy. We often judge between a half a dozen and a dozen exhibits. This comes up every year and gets written up in comments every year. Of course, you can't be harse in judging these things and most of them really do make a legitimate effort, but it is difficult to tactfully explain to someone why their elaborate and extremely detailed results amount to utter jibberish. (To the smartasses who are about to fire off the obligatory smart remarks: Trust me, I am much more tactful with those students than I am on this list... Maybe I shouldn't be. Read that either way.) What's more apalling is that their teachers did not catch this and I have to point out the fatal flaws to a lot of my co-judges who were impressed with the scientific prowess of these individuals. No... The average person, NO, the vast majority of people, DO assume accuracy from decimal places and honestly do not know the difference between precision and accuracy. I've had comments on this thread in private E-Mail the reinforce this impression. Yes, bits are free, sort of... That's why an extra decimal place is "ok". Keeping precision within an order of magnitude of accuracy is within the realm of reasonable. Running out to two decimal places for this particular application is just silly. If it were for calibrated lab equipment, fine. But not for CPU temperatures. Yes, APIs are difficult to change. But can you honestly say that, even if we magically get off the shelf economical temperature sensors that are two orders of magnitude more accurate (without need of constant tracible recalibration - these things DO drift), that this level of precision would have any real meaning at all? I would expect the CPU temperature to vary by a few hundreths of a degree just by how many people were sweating in the cube next to me. Even the rounding error vis-a-vis the .15 is silly and irrelevant! If the sensor is +- 1 degree, you can't even measure the rounding error, even if you HAVE two decimal places. With that degree of accuracy, you are no better off than 273 with no decimal places. Worrying about rounding error on .15 when the accuracy is in the units is exactly the kind of misinformed false precision that I worry about. You actually though that the .15 was significant enough to worry about round error when, in fact, it will be impossible to measure with the equipment available in the environment of discourse. > One might provide other numbers to specify accuracy and precision. Now... That I can agree with and it would make absolute sense. Especially if we were discussing lab grade or scientific grade measure equipment and measurements. In fact, that would be a requirement for any validity to be attached to measurements of that level of precision. But that's not what we are talking about here, is it? We're not talking about a lab grade instrumentation API here, are we? If we are, then everything changes. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Fri, Jun 08, 2001 at 08:43:06PM +0200, J . A . Magallon wrote: > On 06.08 Michael H. Warfield wrote: > > Actually, the REAL point I was TRYING to make (and doing a really > > shabby job of it) is that some of this needs a little dose of reality. > > We don't have sensors that are accurate to 1/10 of a K and certainly not > > to 1/100 of a K. Knowing the CPU temperature "precise" to .01 K when > > the accuracy of the best sensor we are likely to see is no better than > > +- 1 K is just about as relevant as negative absolute temperatures. > Lets see, somebody can develop lab equipment (dont think on PTRs or > thermistors in common world) that givee 10e-3 precission, and you are just > making linux not suitable to control that hardware. Think open. > What is the real difference between managing temperatures with a short > or a long ?. Is it really needed to fit it in a short ??!!! > I would use an unsigned long with fixed point and all done. No, we are not talking lab instrumentation here. We are talking about CPU monitoring. Lab instrumentation is a whole different issue with things like the IEEE bus and such. Lab instrumentation would require it's own drivers and interface. > -- > J.A. Magallon # Let the source be with you... > mailto:[EMAIL PROTECTED] > Linux Mandrake release 8.1 (Cooker) for i586 > Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Fri, Jun 08, 2001 at 08:43:06PM +0200, J . A . Magallon wrote: On 06.08 Michael H. Warfield wrote: Actually, the REAL point I was TRYING to make (and doing a really shabby job of it) is that some of this needs a little dose of reality. We don't have sensors that are accurate to 1/10 of a K and certainly not to 1/100 of a K. Knowing the CPU temperature precise to .01 K when the accuracy of the best sensor we are likely to see is no better than +- 1 K is just about as relevant as negative absolute temperatures. Lets see, somebody can develop lab equipment (dont think on PTRs or thermistors in common world) that givee 10e-3 precission, and you are just making linux not suitable to control that hardware. Think open. What is the real difference between managing temperatures with a short or a long ?. Is it really needed to fit it in a short ??!!! I would use an unsigned long with fixed point and all done. No, we are not talking lab instrumentation here. We are talking about CPU monitoring. Lab instrumentation is a whole different issue with things like the IEEE bus and such. Lab instrumentation would require it's own drivers and interface. -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote: The bits are free; the API is hard to change. Sensors might get better, at least on high-end systems. Rounding gives a constant 0.15 degree error. Only the truly stupid would assume accuracy from decimal places. Again, the bits are free; the API is hard to change. Twice a year I'm a judge at science fairs. Once at the local level and once at the state level. I generally judge on the senior level in the physics category. All too often I have a hard time even convincing some of my fellow judges. Each year there is at least one project where some student has used fancy scientific equipment to make measurements of impressive precision and beautiful results. Till you look closer and you find that their standard deviation is as large as their averages and their raw test results are all over the map. With 5 or more decimal places of precision, you find that their sample sizes and proceedures don't even support one or two decimal places, if they are lucky. If it were not for the fact that I don't think they are really that good at it, I would give them an award for if you can't dazzle them with brilliance, baffle them with bullshit. Unfortunately, they honestly don't KNOW the difference between precision and accuracy. We often judge between a half a dozen and a dozen exhibits. This comes up every year and gets written up in comments every year. Of course, you can't be harse in judging these things and most of them really do make a legitimate effort, but it is difficult to tactfully explain to someone why their elaborate and extremely detailed results amount to utter jibberish. (To the smartasses who are about to fire off the obligatory smart remarks: Trust me, I am much more tactful with those students than I am on this list... Maybe I shouldn't be. Read that either way.) What's more apalling is that their teachers did not catch this and I have to point out the fatal flaws to a lot of my co-judges who were impressed with the scientific prowess of these individuals. No... The average person, NO, the vast majority of people, DO assume accuracy from decimal places and honestly do not know the difference between precision and accuracy. I've had comments on this thread in private E-Mail the reinforce this impression. Yes, bits are free, sort of... That's why an extra decimal place is ok. Keeping precision within an order of magnitude of accuracy is within the realm of reasonable. Running out to two decimal places for this particular application is just silly. If it were for calibrated lab equipment, fine. But not for CPU temperatures. Yes, APIs are difficult to change. But can you honestly say that, even if we magically get off the shelf economical temperature sensors that are two orders of magnitude more accurate (without need of constant tracible recalibration - these things DO drift), that this level of precision would have any real meaning at all? I would expect the CPU temperature to vary by a few hundreths of a degree just by how many people were sweating in the cube next to me. Even the rounding error vis-a-vis the .15 is silly and irrelevant! If the sensor is +- 1 degree, you can't even measure the rounding error, even if you HAVE two decimal places. With that degree of accuracy, you are no better off than 273 with no decimal places. Worrying about rounding error on .15 when the accuracy is in the units is exactly the kind of misinformed false precision that I worry about. You actually though that the .15 was significant enough to worry about round error when, in fact, it will be impossible to measure with the equipment available in the environment of discourse. One might provide other numbers to specify accuracy and precision. Now... That I can agree with and it would make absolute sense. Especially if we were discussing lab grade or scientific grade measure equipment and measurements. In fact, that would be a requirement for any validity to be attached to measurements of that level of precision. But that's not what we are talking about here, is it? We're not talking about a lab grade instrumentation API here, are we? If we are, then everything changes. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Fri, Jun 08, 2001 at 01:33:44PM -0800, Leif Sawyer wrote: From: L. K. [mailto:[EMAIL PROTECTED]] I really do not belive that for a CPU or a motherboard +- 1 degree would make any difference. You haven't pushed your system, or run it in a hostile environment then. There are many places where systems are run right up to the edge of thermal breakdown, and it's a firm requirement to know exactly what that edge is. If a CPU runs fine at, say, 37 degrees C, I do not belive it will have any problems running at 38 or 36 degrees. I support the ideea of having very good sensors for temperature monitoring, but CPU and motherboard temperature do not depend on the rise of the temperature of 1 degree, but when the temperature rises 10 or more degrees. I hope you understand what I want to say. I have a CPU that runs great up to 43C, and shuts down hard at 44C so I obviously want to know how close I am to that. I don't want rounding errors to get in the way, and I don't want changes between kernel revs to affect it either. If the rounding errors are less than the accuracy and the reproducibility of your sensor, and you operate in that range and depend on those values, then you have no clue where you are, no matter what your granularity. You sound like the classic example of why we should NOT do this. You are foolish enough to depend on that precision and think that it's accuracy and think that it means something in comparision to the identical measurement 15 minutes later. It does not. If we've got the bitspace, keep the counters as granular as possible within the useable range that we're designing for. counter = .01 * degrees kelvin Then you are being foolish. Your sensors are neither accurate to that degree nor are they reproducible to that degree. What you are describing is jibberish. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Thu, Jun 07, 2001 at 08:03:58PM -0400, Albert D. Cahalan wrote: > Chris Boot writes: > > >>>> Kelvins good idea in general - it is always positive ;-) > >>>> > >>>> 0.01*K fits in 16 bits and gives reasonable range. > ... > > OK, I think by now we've all agreed the following: > > - The issue is NOT displaying temperatures to the user, but a userspace > >program reading them from the kernel. The userspace program itself can > >do temperature conversions for the user if he/she wants. > > - The most preferable units would be decikelvins, as the value can give a > >relatively precise as well as wide range of numbers ranging from absolute > >zero to about 6340 degrees Celsius ((65535 / 10) - 273) which is well > >within anything that a computer can operate. It also gives us a good > >base for all sorts of other temperature sensing devices. > > > > Do we all agree on those now? > > I nearly do. > > There isn't any need to cram the data into 16 bits. > The offset to Celsius is 273.15 degrees. > So hundredths of a degree, in Kelvin, is a better choice. [Let's see if I can argue boths sides of this fence plus a third here.] Who cares if you cram it into 16 bits. It still works. I think we can agree that negative degrees Kelvin are not relevant (outside of VERY esoteric physics circles where negative absolute temperatures are real and represent quantum mechanical states in "population inversions". i.e. Quantum mechanical temperatures hotter than infinite - reference SciAm back in the mid 1970s. I won an arguement with a PhD high energy physics prof over that point back then). Therefore, we have a 16 bit unsigned quantity which gives us a range of 0 - 65535. Translated as hundreths of a Kelvin, that works out to 0 -> 655.35 K. Ok... That's -273.15 C -> 382.20 C. And... That's roughly -524 F -> 720 F. Ok... That covers everything from superfluid Helium through MELTS GLASS with room for bobble. In 16 bits. What's the problem? Other than what's the need for two digits of precision in something that does not have even 1/100 of that accuracy? A plague of many measuring systems is "false precision". Why provide precision (the units to which a measurement can be divided or quantized) when the accuracy can not support it. I would be amazed if ANY CPU temperature monitors were any more accurate than to a degree C/K or ~2 degrees F). Hundreths of a degree K is basically silly nonsense. The precision even for tenths of a degree K or C are just not supported by the accuracy of the measuring device and are meaningless. Even if it COULD provide even something remotely similar to that level of precision in it's accuracy, is it really relevant to know the CPU temperature to 1/100 of a degree C? Looking at most temperature measuring chips today, unless you are looking at lab-quality high-precision high-accuracy sensors, you are really talking about a 12 bit sensor (+- a couple of bits) with an accuracy of not much better than +-1 C. Add the tenths if you want to be silly but returning hundreths is just meaningless jibberish. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Thu, Jun 07, 2001 at 09:30:54PM +, mirabilos {Thorsten Glaser} wrote:
> It was posted by L. K. where I now add my 0.02 EUR...
> > On Thu, 7 Jun 2001, Albert D. Cahalan wrote:
> > > Negative temperatures do not really exist.
> > Are you really sure about this ?
> I am. I made Abitur (german degree after 13yrs of school)
> with physics being an important course, and there can not
> be any temperature less than 0 K (or -273.15°C if you want).
> This is because temperature is nothing but the movement of
> pieces of materie (and even photons, ergo energy).
Then you must have blown your quantum finals. Royally. ESPECIALLY
after that statement about "temperature is nothing but the movement of
pieces of materie". Not even close, once you get into the quant.
Mathematically and quantum mechanically, negative absolute
temperatures do exist. In quantum mechanics, temperature is expressed as
probability populations in various quantum states.
Absolute zero is the quantum state were all particles are in
the ground state. An infinite temperature is, quantum mechanically,
the condition where all states, ground and energetic, have an equal
probability of population.
A "population inversion" (a condition where the energized states
are more likely to be populated than the ground states) is at the heart
of many things we take for granted today such as lasers, masers, leds,
NMR (Nuclear Magnetic Resonance) and MRI (the medical use of NMR).
Those "population inversions" represents an "energized state"
that is more energetic than the state that would be present in a steady
state infinite temperature.
Mathematically, those states can actually be treated as negative
absolute temperatures. IOW, negative absolute temperatures are actually
hotter than infinite.
It's true that these are not STEADY STATE conditions or in
equilibrium (which is how we take advantage of populations inversions -
by their actions in returning to equilibrium), but the math still works.
Just check out a few issues of Scientific American from the mid 1970's
on "Negative Absolute Temperatures in Nuclear Magnetic Resonance" and
to the scientific journals they reference. I won an argument with
a physics prof (PhD in high energy physics) over that very issue when
I did the same thing in a 400 level senior level physics lab on NMR back
then. It's actually pretty damn simple, once you work the math, and it
agravated him that he didn't believe it but couldn't argue with the math
till he saw the work and publication from someone else. Then he conceeded
that I had him and I had been right.
IAC... Negative absolute temperatures are about as meaningless
to this particular discussion as is expressing the temperature in 1/100s
of a Kelvin which would have a precision than exceeds the accuracy of
the measuring chips by two orders of magnitude. IOW... Both are silly
and meaningless to this case. One is out of range in magnitude and one
is out of the range of accuracy.
> -mirabilos
> --
> C:\>debug
> -e100 EA F0 FF 00 F0
> -g
> --->Enjoy!
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Thu, Jun 07, 2001 at 09:30:54PM +, mirabilos {Thorsten Glaser} wrote:
It was posted by L. K. where I now add my 0.02 EUR...
On Thu, 7 Jun 2001, Albert D. Cahalan wrote:
Negative temperatures do not really exist.
Are you really sure about this ?
I am. I made Abitur (german degree after 13yrs of school)
with physics being an important course, and there can not
be any temperature less than 0 K (or -273.15°C if you want).
This is because temperature is nothing but the movement of
pieces of materie (and even photons, ergo energy).
Then you must have blown your quantum finals. Royally. ESPECIALLY
after that statement about temperature is nothing but the movement of
pieces of materie. Not even close, once you get into the quant.
Mathematically and quantum mechanically, negative absolute
temperatures do exist. In quantum mechanics, temperature is expressed as
probability populations in various quantum states.
Absolute zero is the quantum state were all particles are in
the ground state. An infinite temperature is, quantum mechanically,
the condition where all states, ground and energetic, have an equal
probability of population.
A population inversion (a condition where the energized states
are more likely to be populated than the ground states) is at the heart
of many things we take for granted today such as lasers, masers, leds,
NMR (Nuclear Magnetic Resonance) and MRI (the medical use of NMR).
Those population inversions represents an energized state
that is more energetic than the state that would be present in a steady
state infinite temperature.
Mathematically, those states can actually be treated as negative
absolute temperatures. IOW, negative absolute temperatures are actually
hotter than infinite.
It's true that these are not STEADY STATE conditions or in
equilibrium (which is how we take advantage of populations inversions -
by their actions in returning to equilibrium), but the math still works.
Just check out a few issues of Scientific American from the mid 1970's
on Negative Absolute Temperatures in Nuclear Magnetic Resonance and
to the scientific journals they reference. I won an argument with
a physics prof (PhD in high energy physics) over that very issue when
I did the same thing in a 400 level senior level physics lab on NMR back
then. It's actually pretty damn simple, once you work the math, and it
agravated him that he didn't believe it but couldn't argue with the math
till he saw the work and publication from someone else. Then he conceeded
that I had him and I had been right.
IAC... Negative absolute temperatures are about as meaningless
to this particular discussion as is expressing the temperature in 1/100s
of a Kelvin which would have a precision than exceeds the accuracy of
the measuring chips by two orders of magnitude. IOW... Both are silly
and meaningless to this case. One is out of range in magnitude and one
is out of the range of accuracy.
-mirabilos
--
C:\debug
-e100 EA F0 FF 00 F0
-g
---Enjoy!
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Thu, Jun 07, 2001 at 08:03:58PM -0400, Albert D. Cahalan wrote: Chris Boot writes: Kelvins good idea in general - it is always positive ;-) 0.01*K fits in 16 bits and gives reasonable range. ... OK, I think by now we've all agreed the following: - The issue is NOT displaying temperatures to the user, but a userspace program reading them from the kernel. The userspace program itself can do temperature conversions for the user if he/she wants. - The most preferable units would be decikelvins, as the value can give a relatively precise as well as wide range of numbers ranging from absolute zero to about 6340 degrees Celsius ((65535 / 10) - 273) which is well within anything that a computer can operate. It also gives us a good base for all sorts of other temperature sensing devices. Do we all agree on those now? I nearly do. There isn't any need to cram the data into 16 bits. The offset to Celsius is 273.15 degrees. So hundredths of a degree, in Kelvin, is a better choice. [Let's see if I can argue boths sides of this fence plus a third here.] Who cares if you cram it into 16 bits. It still works. I think we can agree that negative degrees Kelvin are not relevant (outside of VERY esoteric physics circles where negative absolute temperatures are real and represent quantum mechanical states in population inversions. i.e. Quantum mechanical temperatures hotter than infinite - reference SciAm back in the mid 1970s. I won an arguement with a PhD high energy physics prof over that point back then). Therefore, we have a 16 bit unsigned quantity which gives us a range of 0 - 65535. Translated as hundreths of a Kelvin, that works out to 0 - 655.35 K. Ok... That's -273.15 C - 382.20 C. And... That's roughly -524 F - 720 F. Ok... That covers everything from superfluid Helium through MELTS GLASS with room for bobble. In 16 bits. What's the problem? Other than what's the need for two digits of precision in something that does not have even 1/100 of that accuracy? A plague of many measuring systems is false precision. Why provide precision (the units to which a measurement can be divided or quantized) when the accuracy can not support it. I would be amazed if ANY CPU temperature monitors were any more accurate than to a degree C/K or ~2 degrees F). Hundreths of a degree K is basically silly nonsense. The precision even for tenths of a degree K or C are just not supported by the accuracy of the measuring device and are meaningless. Even if it COULD provide even something remotely similar to that level of precision in it's accuracy, is it really relevant to know the CPU temperature to 1/100 of a degree C? Looking at most temperature measuring chips today, unless you are looking at lab-quality high-precision high-accuracy sensors, you are really talking about a 12 bit sensor (+- a couple of bits) with an accuracy of not much better than +-1 C. Add the tenths if you want to be silly but returning hundreths is just meaningless jibberish. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TRG vger.timpanogas.org hacked
On Tue, Jun 05, 2001 at 11:30:51AM -0700, Jeff V. Merkey wrote: > On Tue, Jun 05, 2001 at 08:05:34AM +0100, Alan Cox wrote: > > > is curious as to how these folks did this. They exploited BIND 8.2.3 > > > to get in and logs indicated that someone was using a "back door" in > > Bind runs as root. > > > We are unable to determine just how they got in exactly, but they > > > kept trying and created an oops in the affected code which allowed > > > the attack to proceed. > > Are you sure they didnt in fact simply screw up live patching the kernel to > > cover their traces > Could have. The kernel is unable to dismount the root volume when booted. > I can go through the drive and remove confidential stuffd and just leave > the system intact and post the entire system image to my ftp server. This would be a good thing for those of us involved in investigating these sorts of things. :-/ > I have changed all the passwords on the server, so what's there is no > big deal. This server was public FTP and web/email, so nothing really > super "confidential" on it. > Jeff Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TRG vger.timpanogas.org hacked
On Tue, Jun 05, 2001 at 08:05:34AM +0100, Alan Cox wrote: > > is curious as to how these folks did this. They exploited BIND 8.2.3 > > to get in and logs indicated that someone was using a "back door" in > Bind runs as root. It doesn't have to. In fact, I just set up a RedHat 6.2 Honeypot a couple of weeks ago researching Bind based worms that are becoming a problem. Much to my surprise, that OOB RedHat 6.2 system ran bind as "named -u named" and was running Bind under a common user id. RedHat 6.0 runs it as root and I haven't checked 6.1 yet. Don't know about the other distros, yet. > > We are unable to determine just how they got in exactly, but they > > kept trying and created an oops in the affected code which allowed > > the attack to proceed. > Are you sure they didnt in fact simply screw up live patching the kernel to > cover their traces That would be a hint that they MIGHT have been trying to get a Linux kernel stealth module going. Several of the worms I'm looking at include the Adore LKM to hide processes, files, and sockets. That worm (as several others like it) also upgrade the version of Bind they broke in through to prevent further compromise. There will be a security advisory out on these worms, probably later this week. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TRG vger.timpanogas.org hacked
On Tue, Jun 05, 2001 at 08:05:34AM +0100, Alan Cox wrote: is curious as to how these folks did this. They exploited BIND 8.2.3 to get in and logs indicated that someone was using a back door in Bind runs as root. It doesn't have to. In fact, I just set up a RedHat 6.2 Honeypot a couple of weeks ago researching Bind based worms that are becoming a problem. Much to my surprise, that OOB RedHat 6.2 system ran bind as named -u named and was running Bind under a common user id. RedHat 6.0 runs it as root and I haven't checked 6.1 yet. Don't know about the other distros, yet. We are unable to determine just how they got in exactly, but they kept trying and created an oops in the affected code which allowed the attack to proceed. Are you sure they didnt in fact simply screw up live patching the kernel to cover their traces That would be a hint that they MIGHT have been trying to get a Linux kernel stealth module going. Several of the worms I'm looking at include the Adore LKM to hide processes, files, and sockets. That worm (as several others like it) also upgrade the version of Bind they broke in through to prevent further compromise. There will be a security advisory out on these worms, probably later this week. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TRG vger.timpanogas.org hacked
On Tue, Jun 05, 2001 at 11:30:51AM -0700, Jeff V. Merkey wrote: On Tue, Jun 05, 2001 at 08:05:34AM +0100, Alan Cox wrote: is curious as to how these folks did this. They exploited BIND 8.2.3 to get in and logs indicated that someone was using a back door in Bind runs as root. We are unable to determine just how they got in exactly, but they kept trying and created an oops in the affected code which allowed the attack to proceed. Are you sure they didnt in fact simply screw up live patching the kernel to cover their traces Could have. The kernel is unable to dismount the root volume when booted. I can go through the drive and remove confidential stuffd and just leave the system intact and post the entire system image to my ftp server. This would be a good thing for those of us involved in investigating these sorts of things. :-/ I have changed all the passwords on the server, so what's there is no big deal. This server was public FTP and web/email, so nothing really super confidential on it. Jeff Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFF-TOPIC] 4 ports ETH cards
On Wed, May 30, 2001 at 06:34:16PM -0300, Harald Welte wrote: > On Tue, May 29, 2001 at 09:52:41AM +0200, Fabbione wrote: > > Hi all, > > sorry for the offtopic msg. > > > > Can someone point me to a 4 ports fast/eth card solution for linux? > D-Link DFE-570 has a reasonable pricing and is well supported by the > tulip driver Just got three of these suckers and I'm about to order a bunch more (happy camper)... > > I found some cards based on the DEC 21*4* chips but when > > I asked for more details I got a strange answer from the reseller > > like that this card is able to work only half-duplex and the chip has > > only one mac-address for the 4 eth cards (really strange). > nah. And even if so, you can always change the mac-address using ifconfig. Each D-Link card has four MAC addresses (sequential). I doubt other manufactures are any different. > What the guy most likely wanted to say, is that there is only one EEprom > containing all mac adresses for the four tulip chips, which I have seen > on multiple boards What the guy was doing was having a bad case of optical rectitus. That would be typical of a "reseller" (AKA Salesman). Most would not even have a CLUE that the cards were based on the tulip chipset / driver. Because the D-Link cards were less than half of the nearest competitor [ < $180 vs > $360 for others and Compac was > $2400! ] I ordered only three not knowing for sure if they would work. Turned on the tulip driver and them suckers fired right up. Now I know they work, stock, right out of the box, and I can order a bunch more for the lab I'm working with. > > Thanks a lot > > Fabbione > > -- > Live long and prosper > - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFF-TOPIC] 4 ports ETH cards
On Wed, May 30, 2001 at 06:34:16PM -0300, Harald Welte wrote: On Tue, May 29, 2001 at 09:52:41AM +0200, Fabbione wrote: Hi all, sorry for the offtopic msg. Can someone point me to a 4 ports fast/eth card solution for linux? D-Link DFE-570 has a reasonable pricing and is well supported by the tulip driver Just got three of these suckers and I'm about to order a bunch more (happy camper)... I found some cards based on the DEC 21*4* chips but when I asked for more details I got a strange answer from the reseller like that this card is able to work only half-duplex and the chip has only one mac-address for the 4 eth cards (really strange). nah. And even if so, you can always change the mac-address using ifconfig. Each D-Link card has four MAC addresses (sequential). I doubt other manufactures are any different. What the guy most likely wanted to say, is that there is only one EEprom containing all mac adresses for the four tulip chips, which I have seen on multiple boards What the guy was doing was having a bad case of optical rectitus. That would be typical of a reseller (AKA Salesman). Most would not even have a CLUE that the cards were based on the tulip chipset / driver. Because the D-Link cards were less than half of the nearest competitor [ $180 vs $360 for others and Compac was $2400! ] I ordered only three not knowing for sure if they would work. Turned on the tulip driver and them suckers fired right up. Now I know they work, stock, right out of the box, and I can order a bunch more for the lab I'm working with. Thanks a lot Fabbione -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
Hello, I'm tunning into this discussion a little late, but... On Mon, Apr 30, 2001 at 01:22:59PM -0700, Francois Gouget wrote: > On Mon, 30 Apr 2001, Jeff Garzik wrote: > > Francois Gouget wrote: > > > CONFIG_PCMCIA=y > > > CONFIG_CARDBUS=y > > > CONFIG_I82365=y > > > > Not correct -- you do not need I82365 if you have CardBus. However, if > > you are running 2.4.4 you should be ok. >Ok. I upgraded to 2.4.4 and modified my config file to be: > CONFIG_PCMCIA=y > CONFIG_CARDBUS=y > # CONFIG_I82365 is not set >But now I get the same missing symbols I initially had in 2.4.3: > Apr 30 13:19:34 oleron cardmgr[148]: initializing socket 0 > Apr 30 13:19:34 oleron cardmgr[148]: socket 0: Aironet PC4800 > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_core' > Apr 30 13:19:34 oleron cardmgr[148]: + Warning: >/lib/modules/2.4.4/kernel/drivers/net/aironet4500_core.o > symbol for parameter rx_queue_len not found > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_proc' > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_cs' > Apr 30 13:19:35 oleron cardmgr[148]: get dev info on socket 0 > failed: Resource temporarily unavailable Seen this before. What version are your modutils at? Latest are 2.4.5 on kernel.org and there have been several times where I've had them slip out of rev and ended up with missing symbols. > -- > Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ > 1 + e ^ ( i * pi ) = 0 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
Hello, I'm tunning into this discussion a little late, but... On Mon, Apr 30, 2001 at 01:22:59PM -0700, Francois Gouget wrote: On Mon, 30 Apr 2001, Jeff Garzik wrote: Francois Gouget wrote: CONFIG_PCMCIA=y CONFIG_CARDBUS=y CONFIG_I82365=y Not correct -- you do not need I82365 if you have CardBus. However, if you are running 2.4.4 you should be ok. Ok. I upgraded to 2.4.4 and modified my config file to be: CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_I82365 is not set But now I get the same missing symbols I initially had in 2.4.3: Apr 30 13:19:34 oleron cardmgr[148]: initializing socket 0 Apr 30 13:19:34 oleron cardmgr[148]: socket 0: Aironet PC4800 Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_core' Apr 30 13:19:34 oleron cardmgr[148]: + Warning: /lib/modules/2.4.4/kernel/drivers/net/aironet4500_core.o symbol for parameter rx_queue_len not found Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_proc' Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_cs' Apr 30 13:19:35 oleron cardmgr[148]: get dev info on socket 0 failed: Resource temporarily unavailable Seen this before. What version are your modutils at? Latest are 2.4.5 on kernel.org and there have been several times where I've had them slip out of rev and ended up with missing symbols. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Worm (fwd)
On Fri, Mar 23, 2001 at 10:31:49AM -0800, Gerhard Mack wrote: > On Fri, 23 Mar 2001, Bob Lorenzini wrote: > > I'm annoyed when persons post virus alerts to unrelated lists but this > > is a serious threat. If your offended flame away. > This should be a wake up call... distributions need to stop using product > with consistently bad security records. Bullshit. This is a wake up call that admins need to keep installations up to date. When a security hole is found, I DON'T CARE if it's in a package with a good security record or a poor security record. It has to be fixed and you can't put it off. Certainly not in the current climate with script driven worms like Ramen and 1i0n. Having a poor security record is a warning to the developers that it's time to clean up their act and do better. Sendmail use to be the bug of the month club. Hell! It use to be the bug of the week club. Last couple of years, it's been pretty solid. If you only went on security track record, we would all be using MMDF, which is still arguibly the most secure mail transport around. MMDF has had what? One advisory in something like 15 years of deployment? It was the default MTA in SCO Unix for years and was mandated at military installations for a long time... Still, when that one advisory comes out, you better update or you are toast. You don't solely rely on packages that have "good security records" never getting broken and then become complacent. Sites that do that are what we call "Warez" sites. :-/ > Gerhard > -- > Gerhard Mack > [EMAIL PROTECTED] > <>< As a computer I find your faith in technology amusing. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Worm (fwd)
On Fri, Mar 23, 2001 at 10:31:49AM -0800, Gerhard Mack wrote:
On Fri, 23 Mar 2001, Bob Lorenzini wrote:
I'm annoyed when persons post virus alerts to unrelated lists but this
is a serious threat. If your offended flame away.
This should be a wake up call... distributions need to stop using product
with consistently bad security records.
Bullshit.
This is a wake up call that admins need to keep installations up
to date. When a security hole is found, I DON'T CARE if it's in a package
with a good security record or a poor security record. It has to be
fixed and you can't put it off. Certainly not in the current climate
with script driven worms like Ramen and 1i0n.
Having a poor security record is a warning to the developers that
it's time to clean up their act and do better. Sendmail use to be the
bug of the month club. Hell! It use to be the bug of the week club. Last
couple of years, it's been pretty solid. If you only went on security
track record, we would all be using MMDF, which is still arguibly the most
secure mail transport around. MMDF has had what? One advisory in something
like 15 years of deployment? It was the default MTA in SCO Unix for
years and was mandated at military installations for a long time... Still,
when that one advisory comes out, you better update or you are toast.
You don't solely rely on packages that have "good security records"
never getting broken and then become complacent. Sites that do that are
what we call "Warez" sites. :-/
Gerhard
--
Gerhard Mack
[EMAIL PROTECTED]
As a computer I find your faith in technology amusing.
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sun, Feb 18, 2001 at 12:00:03PM -0600, Gregory S. Youngblood wrote: > On Sun, 18 Feb 2001, Michael H. Warfield wrote: > > On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote: > > > > > > > > On the other hand, they make excellent mice. The mouse wheel and > > > > the new optical mice are truly innovative and Microsoft should be > > > > commended for them. > > > > > > > The wheel was a nifty idea, but I've seen workstations 15 years old with > > > optical mice. It wasn't MS's idea. > > I think their "innovation" was not requiring the optical cross > > grid mouse pad common on Sun workstations over the years. The Microsoft > > optical mouse uses variations in the surface characteristics of whatever > > it's on to perform it's function. The old optical mice just used two > > different colors of LED's (red and IR) and a special pad. This would > > actually have to scan and track the surface below it. Don't know that > > I've seen anyone do that before. > I remember being at a computer show in Minneapolis where a small company > was showing off this mouse that worked on a variety of surfaces without a > ball. I'm trying to remember if the mouse was optical or used yet another > method of functioning -- I think it was optical, though I could be > mistaken. This was in 1992/1993. I think you are correct here. I seem to recall mention of some of those earlier devices at the time of the Microsoft announcement. I seem to also recall some of the reliability problem they had. I believe they were extremely fussy about the surface they were on. > The point is, I really do not believe Microsoft made the "leap" to provide > opitcal mice without the need of the mousepad grid. Their "innovation" was > in marketing it on a wide scale though. I would agree there. They did something to improve the reliability on a wider variety of surface textures, though. Is that innovation or merely getting a good idea, that's been around, to finally work? Don't know. I didn't find the idea itself particularly innovative. The fact that they did get it to work reliable is something to be said. The marketing is a given, of course. Particularly in the face of the preception in some camps that this style of optical mouse was unreliable. > I could be mistaken - if so then let's give them their credit - but I have > a hard time believing it was their idea without some serious proof. Agreed. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote: > > > > On the other hand, they make excellent mice. The mouse wheel and > > the new optical mice are truly innovative and Microsoft should be > > commended for them. > > > The wheel was a nifty idea, but I've seen workstations 15 years old with > optical mice. It wasn't MS's idea. I think their "innovation" was not requiring the optical cross grid mouse pad common on Sun workstations over the years. The Microsoft optical mouse uses variations in the surface characteristics of whatever it's on to perform it's function. The old optical mice just used two different colors of LED's (red and IR) and a special pad. This would actually have to scan and track the surface below it. Don't know that I've seen anyone do that before. > -b Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sun, Feb 18, 2001 at 12:00:03PM -0600, Gregory S. Youngblood wrote:
On Sun, 18 Feb 2001, Michael H. Warfield wrote:
On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote:
On the other hand, they make excellent mice. The mouse wheel and
the new optical mice are truly innovative and Microsoft should be
commended for them.
The wheel was a nifty idea, but I've seen workstations 15 years old with
optical mice. It wasn't MS's idea.
I think their "innovation" was not requiring the optical cross
grid mouse pad common on Sun workstations over the years. The Microsoft
optical mouse uses variations in the surface characteristics of whatever
it's on to perform it's function. The old optical mice just used two
different colors of LED's (red and IR) and a special pad. This would
actually have to scan and track the surface below it. Don't know that
I've seen anyone do that before.
I remember being at a computer show in Minneapolis where a small company
was showing off this mouse that worked on a variety of surfaces without a
ball. I'm trying to remember if the mouse was optical or used yet another
method of functioning -- I think it was optical, though I could be
mistaken. This was in 1992/1993.
I think you are correct here. I seem to recall mention of some
of those earlier devices at the time of the Microsoft announcement. I
seem to also recall some of the reliability problem they had. I believe
they were extremely fussy about the surface they were on.
The point is, I really do not believe Microsoft made the "leap" to provide
opitcal mice without the need of the mousepad grid. Their "innovation" was
in marketing it on a wide scale though.
I would agree there. They did something to improve the reliability
on a wider variety of surface textures, though. Is that innovation or
merely getting a good idea, that's been around, to finally work? Don't
know. I didn't find the idea itself particularly innovative. The fact
that they did get it to work reliable is something to be said.
The marketing is a given, of course. Particularly in the face
of the preception in some camps that this style of optical mouse was
unreliable.
I could be mistaken - if so then let's give them their credit - but I have
a hard time believing it was their idea without some serious proof.
Agreed.
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 02:38:19PM -0800, Andre Hedrick wrote: > On Sat, 17 Feb 2001, Dennis wrote: > > good commercial drivers dont need fixing. another point. You are arguing > > that having source is required to fix crappy code, which i agree with. > > You "guys" like to have source, and there is nothing wrong with that. But > > requiring that all code be distributed as source DOES stifle innovation. > > Its as simple as that. > And when your customer gets screw because you refuse to update your binary > driver because you do not know or have had the chance to follow any > evolving API, you are going to blame us in OPEN source, right. At our office, we actually had a sysadmin suggest that the reason we had problems with viruses propagating was because they couldn't put everyone on Exchange (some of us use Unix/Linux) and that was causing the problems. Of course... Operating systems which are immune to these things are to blame for the epidemics on the ones that are suceptible. That makes sense. G Of course the availablity of quality drivers with sources are the reason for crappy closed source drivers... I can see his reasoning (isn't that scary). <;-/=/ Actually, it does make a perverted sort of sense. If we didn't have systems that didn't have these problems, nobody would think that there was anything wrong. They would just think that "of course, this is what you expect from suppliers". They would have no yardstick to measure against, so rebooting a computer once a day or having a blue screen would just be part of the normal experience. So we DO contribute to his problems! We provide a standard which he can not live up to or even pursue given the manpower and talent he may have (or not have). How is he suppose to innovate when the Open Source community is setting such a high standard for him? :->=> > Meanwhile the API changes may have boosted the performance factor and you > have screw yourself and customer base because you are to lame to see the > value of open source. > > Some time ago I proposed CLAPI, and you are one of the venders that would > benefit from such a beast. This model would have required you to LGPL a > kernel library that would have all the functional IP (that is not IP) that > is to lame to be placed into the hardware. If your hardware is so flakey > that you have to pump/prime it for operationswellyou get the > point. > > If I recall you and your company on one of the worst offenders of taking > code (GPL or not) and changing it and putting it out as binaries. I am > surprized that you have not been taken down yet. Then if someone asks for > the return of the code base and changes because they can under the terms > of the license that you removed from that code, you charge them a fee and > suggest actionable terms if any disclosure into the public form from > where it came. Well... Yeah... Of course, Andre. Can you see how that stiffles his innovation. > Regards, Later! > Andre Hedrick > Linux ATA Development Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation... [way O.T.]
On Sat, Feb 17, 2001 at 02:56:15PM -0500, Dennis wrote: > At 05:59 PM 02/16/2001, John Cavan wrote: > >Dennis wrote: > > > objective, arent we? > > > >You might ask yourself the same question... > > > For example, if there were six different companies that marketed ethernet > > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps > > > with different "features" that were of value to you. Instead, you have > > > crappy GPL code that locks up under load, and its not worth spending > > > corporate dollars to fix it because you have to give away your work for > > > free under GPL. And since there is a "free" driver that most people can > > > use, its not worth building a better mousetrap either because the market is > > > too small. So, the handful of users with problems get to "fit it > > > themselves", most of whom cant of course. > >A large bulk of the investment in Linux is starting to come in from > >hardware manufacturers, notably IBM. These companies see Linux as a > >means to sell more hardware, not as a means to sell software. This is > >critical, because it means that it IS worth the money to make the driver > >perform correctly, GPL or not, because a bad driver means no sales. > Thats wrong. The eepro100 is a great example. It works for most people, so > the market for an improved one is very limited. Your market is not the > whole community, only the community that needs something better. IBM will > simply blame linux if it cant handle a situation. They arent supporting > linux, they are only taking advantage of the fact that people want it. Excuse me? A 1 billion dolar investment in Linux is not supporting it? Setting up tier 1 and tier 2 support services for a half a dozen distributions is not supporting it? Porting their AIX file systems and applications is not supporting it? Porting it to the 390 is not supporting it? You bet'cha they are taking advantage of the fact that people want it. They would be damn fools in business if they didn't take advantage of that. And that means supporting it. It's to their advantage to support it and they see it. You must have a really bizzare idea of what support means... > BSDI is distributing FreeBSD now. They havent done anything useful to > support it. They are just cashing in on it. And your point is??? > DB Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 03:08:48PM -0500, Dennis wrote: > At 07:10 PM 02/16/2001, [EMAIL PROTECTED] wrote: > >Dennis wrote: > >... > > > objective, arent we? > >Nope. Are you claiming to be? > > > > > For example, if there were six different companies that marketed ethernet > > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps > >... Rant deleted > > > >I had a problem with eepro100. > >It was fixed same night cause I had the source. > >Don't even try to compare with MickyS**t. > good commercial drivers dont need fixing. another point. You are arguing > that having source is required to fix crappy code, which i agree with. Then good commercial drivers == blivit. Ain't no such critter. They are always late and buggy and then take forever to get fixed. Nature of the close source development cycle with deadlines and project managers that say "we can afford to wait any longer, we have to ship it now and fix the bugs after release". > You "guys" like to have source, and there is nothing wrong with that. But > requiring that all code be distributed as source DOES stifle innovation. > Its as simple as that. Sorry but it's time to pull it out, smell the air, and buy a clue. There are people out there right now delivering binary modules and binary pieces for device drivers in the kernel. I'm working with one right now. They are providing partial sources with a binary library (this is the Lucent WaveLan wvlan2_cs drivers). Nothing is required. But binary drivers don't get the support from the open source people that the open source drivers get. Sounds reasonable to me. There are other binary only drivers (to say nothing of applications) both freeware and payware out there. I've got people working on some myself. So your arguement that "requiring that all code be distributed as source DOES stifle innovation" fails on it's premise because it's NOT REQUIRED. Just don't expect us to kiss your merry ass and fall over backwards meeting your demands when you DO deliver a binary only driver. If people like it, fine. If they don't, whose problem is that? The idea that nobody will pay for OpenSource software is a myth. I buy software for Linux all the time. I buy closed source software and I buy open source software. The only difference is the presence of the sources. So what. Tell me how that makes those products less innovative? Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
ggest thing that the linux community does to stifle innovation is to > > > bash commercial vendors trying to make a profit by whining endlessly about > > > "sourceless" distributions and recommending "open-source" solutions even > > > when they are wholly inferior. You're only hurting yourselves in the long > > > run. In that respect MS is correct, because those with the dollars to > > > innovate will stay away. > > > >You claim that "open source solutions are wholely inferior to closed > >source solutions". > > > >H... > > > >Then why does everyone run with Apache instead of IIS? Could it be that > >IIS is a piece of crap? > > > >Feature for feature I would rather use PHP 4 over ColdFusion any day. > > > >Sendmail is MUCH more stable than Exchange. (Even if it has config files > >that look like they were designed by Carlos Castanada on a bad day.) If > >not Sendmail, there are a couple of other Open Source mail programs that > >are much superior in quality than the closed source counterparts. > > > >As for the Linux kernel being "shoddy"... > > > >Since when? > > > >I can leave my Linux box running over night and actually have it do > >things! I cannot say the same for Windows. I leave that running (same > >hardware, different OS) and it is usually dead by dawn. > > > >But your argument is even more bogus than that. > > > >It seems that you argument boils down to a couple of thing... > > > >"Closed source is better because you pay money for it." > > > >"Closed source is superior because we have a company name and you don't." > > > >Sorry, but most of the people who develop Open Source are profesional > >programmers. They just have a different motivation. > > > >Open Source is motivated by pride in what you can do and a desire to help > >others by sharing that. They don't hide behind a wall of lawyers to keep > >people from finding out what they did wrong. > > > >I found out a long time ago that most "Trade Secret" claims were bogus. > >It was either a common technique that had been adapted to a particular > >purpose or it was being used as an excuse to hide how bad the code really > >was. > > > >But my experiences with Open Source, as well as the others I know who use > >it are quite telling. > > > >If I have a problem with an Open Source program I can look at the code and > >fix it. Or I can report the bug and it will get fixed soon after. The > >programmers involved put the effort into it because their name is > >attached. > > > >My experiences with closed source companies are not as good. > > > >In many cases, I was ignored because I did not represent a fortune 500 > >company. If the problem got fixed at all, it would be months before I saw > >it and usually in a later release that I would have to pay for. (Usually > >having features added that I neither wanted or would ever use.) In some > >cases (like Microsoft security bugs) it would be treated like a public > >relations problem instead of a software and quality issue. > > > >I have also seen cases where problems were buried in development because > >"no one will find out and if they do, we will just blame Microsoft". > > > >I understand your desire to make money off what you do for a living. I do > >object to you taring what I do as somehow damaging to the software > >industry as a whole. (Especially since the closed source software > >industry has been poaching off the open source community for years. > >Microsoft seeking enlightenment with WinXP is only a minor example.) > > > >I don't see how hiding how something works adds value to the process. > > > >[EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply > >Alan Olsen| to my mail, just hit the ctrl, alt and del keys. > > "In the future, everything will have its 15 minutes of blame." > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
ate will stay away. You claim that "open source solutions are wholely inferior to closed source solutions". H... Then why does everyone run with Apache instead of IIS? Could it be that IIS is a piece of crap? Feature for feature I would rather use PHP 4 over ColdFusion any day. Sendmail is MUCH more stable than Exchange. (Even if it has config files that look like they were designed by Carlos Castanada on a bad day.) If not Sendmail, there are a couple of other Open Source mail programs that are much superior in quality than the closed source counterparts. As for the Linux kernel being "shoddy"... Since when? I can leave my Linux box running over night and actually have it do things! I cannot say the same for Windows. I leave that running (same hardware, different OS) and it is usually dead by dawn. But your argument is even more bogus than that. It seems that you argument boils down to a couple of thing... "Closed source is better because you pay money for it." "Closed source is superior because we have a company name and you don't." Sorry, but most of the people who develop Open Source are profesional programmers. They just have a different motivation. Open Source is motivated by pride in what you can do and a desire to help others by sharing that. They don't hide behind a wall of lawyers to keep people from finding out what they did wrong. I found out a long time ago that most "Trade Secret" claims were bogus. It was either a common technique that had been adapted to a particular purpose or it was being used as an excuse to hide how bad the code really was. But my experiences with Open Source, as well as the others I know who use it are quite telling. If I have a problem with an Open Source program I can look at the code and fix it. Or I can report the bug and it will get fixed soon after. The programmers involved put the effort into it because their name is attached. My experiences with closed source companies are not as good. In many cases, I was ignored because I did not represent a fortune 500 company. If the problem got fixed at all, it would be months before I saw it and usually in a later release that I would have to pay for. (Usually having features added that I neither wanted or would ever use.) In some cases (like Microsoft security bugs) it would be treated like a public relations problem instead of a software and quality issue. I have also seen cases where problems were buried in development because "no one will find out and if they do, we will just blame Microsoft". I understand your desire to make money off what you do for a living. I do object to you taring what I do as somehow damaging to the software industry as a whole. (Especially since the closed source software industry has been poaching off the open source community for years. Microsoft seeking enlightenment with WinXP is only a minor example.) I don't see how hiding how something works adds value to the process. [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 03:08:48PM -0500, Dennis wrote:
At 07:10 PM 02/16/2001, [EMAIL PROTECTED] wrote:
Dennis wrote:
...
objective, arent we?
Nope. Are you claiming to be?
For example, if there were six different companies that marketed ethernet
drivers for the eepro100, you'd have a choice of which one to buy..perhaps
... Rant deleted
I had a problem with eepro100.
It was fixed same night cause I had the source.
Don't even try to compare with MickyS**t.
good commercial drivers dont need fixing. another point. You are arguing
that having source is required to fix crappy code, which i agree with.
Then good commercial drivers == blivit.
Ain't no such critter. They are always late and buggy and then
take forever to get fixed. Nature of the close source development cycle
with deadlines and project managers that say "we can afford to wait any
longer, we have to ship it now and fix the bugs after release".
You "guys" like to have source, and there is nothing wrong with that. But
requiring that all code be distributed as source DOES stifle innovation.
Its as simple as that.
Sorry but it's time to pull it out, smell the air, and buy a clue.
There are people out there right now delivering binary modules and binary
pieces for device drivers in the kernel. I'm working with one right now.
They are providing partial sources with a binary library (this is the
Lucent WaveLan wvlan2_cs drivers). Nothing is required. But binary drivers
don't get the support from the open source people that the open source
drivers get. Sounds reasonable to me. There are other binary only drivers
(to say nothing of applications) both freeware and payware out there. I've
got people working on some myself. So your arguement that "requiring that
all code be distributed as source DOES stifle innovation" fails on it's
premise because it's NOT REQUIRED. Just don't expect us to kiss your merry
ass and fall over backwards meeting your demands when you DO deliver a
binary only driver. If people like it, fine. If they don't, whose problem
is that? The idea that nobody will pay for OpenSource software is a myth.
I buy software for Linux all the time. I buy closed source software and
I buy open source software. The only difference is the presence of the
sources. So what. Tell me how that makes those products less innovative?
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation... [way O.T.]
On Sat, Feb 17, 2001 at 02:56:15PM -0500, Dennis wrote:
At 05:59 PM 02/16/2001, John Cavan wrote:
Dennis wrote:
objective, arent we?
You might ask yourself the same question...
For example, if there were six different companies that marketed ethernet
drivers for the eepro100, you'd have a choice of which one to buy..perhaps
with different "features" that were of value to you. Instead, you have
crappy GPL code that locks up under load, and its not worth spending
corporate dollars to fix it because you have to give away your work for
free under GPL. And since there is a "free" driver that most people can
use, its not worth building a better mousetrap either because the market is
too small. So, the handful of users with problems get to "fit it
themselves", most of whom cant of course.
A large bulk of the investment in Linux is starting to come in from
hardware manufacturers, notably IBM. These companies see Linux as a
means to sell more hardware, not as a means to sell software. This is
critical, because it means that it IS worth the money to make the driver
perform correctly, GPL or not, because a bad driver means no sales.
Thats wrong. The eepro100 is a great example. It works for most people, so
the market for an improved one is very limited. Your market is not the
whole community, only the community that needs something better. IBM will
simply blame linux if it cant handle a situation. They arent supporting
linux, they are only taking advantage of the fact that people want it.
Excuse me? A 1 billion dolar investment in Linux is not supporting
it? Setting up tier 1 and tier 2 support services for a half a dozen
distributions is not supporting it? Porting their AIX file systems and
applications is not supporting it? Porting it to the 390 is not supporting
it? You bet'cha they are taking advantage of the fact that people want it.
They would be damn fools in business if they didn't take advantage of that.
And that means supporting it. It's to their advantage to support it and
they see it. You must have a really bizzare idea of what support means...
BSDI is distributing FreeBSD now. They havent done anything useful to
support it. They are just cashing in on it.
And your point is???
DB
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 02:38:19PM -0800, Andre Hedrick wrote:
On Sat, 17 Feb 2001, Dennis wrote:
good commercial drivers dont need fixing. another point. You are arguing
that having source is required to fix crappy code, which i agree with.
You "guys" like to have source, and there is nothing wrong with that. But
requiring that all code be distributed as source DOES stifle innovation.
Its as simple as that.
And when your customer gets screw because you refuse to update your binary
driver because you do not know or have had the chance to follow any
evolving API, you are going to blame us in OPEN source, right.
At our office, we actually had a sysadmin suggest that the reason
we had problems with viruses propagating was because they couldn't put
everyone on Exchange (some of us use Unix/Linux) and that was causing the
problems. Of course... Operating systems which are immune to these things
are to blame for the epidemics on the ones that are suceptible. That
makes sense. G Of course the availablity of quality drivers with
sources are the reason for crappy closed source drivers... I can see his
reasoning (isn't that scary). ;-/=/
Actually, it does make a perverted sort of sense. If we didn't
have systems that didn't have these problems, nobody would think that
there was anything wrong. They would just think that "of course, this
is what you expect from suppliers". They would have no yardstick to
measure against, so rebooting a computer once a day or having a blue
screen would just be part of the normal experience. So we DO contribute
to his problems! We provide a standard which he can not live up to or
even pursue given the manpower and talent he may have (or not have).
How is he suppose to innovate when the Open Source community is setting
such a high standard for him? :-=
Meanwhile the API changes may have boosted the performance factor and you
have screw yourself and customer base because you are to lame to see the
value of open source.
Some time ago I proposed CLAPI, and you are one of the venders that would
benefit from such a beast. This model would have required you to LGPL a
kernel library that would have all the functional IP (that is not IP) that
is to lame to be placed into the hardware. If your hardware is so flakey
that you have to pump/prime it for operationswellyou get the
point.
If I recall you and your company on one of the worst offenders of taking
code (GPL or not) and changing it and putting it out as binaries. I am
surprized that you have not been taken down yet. Then if someone asks for
the return of the code base and changes because they can under the terms
of the license that you removed from that code, you charge them a fee and
suggest actionable terms if any disclosure into the public form from
where it came.
Well... Yeah... Of course, Andre. Can you see how that stiffles
his innovation.
Regards,
Later!
Andre Hedrick
Linux ATA Development
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Fri, Feb 16, 2001 at 04:35:02PM -0800, Dan Hollis wrote:
> On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote:
> > I did some research on the patent database and found nothing regarding such
> > a patent. There's patent on word processors (not the concept but related to)
> > and uses tab on the description...and that patent is from 1980.
> You know XOR is patented (yes, the logical bit operation XOR).
But wasn't that Xerox that had that? Yeah, the same ones that
screwed us over with the compression patent that shot .gif images out
of the sky. There was inovation for you.
> -Dan
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Fri, Feb 09, 2001 at 01:50:04AM +, Aaron Denney wrote: > Michael H. Warfield <[EMAIL PROTECTED]> wrote: > > But, wait a minute. CNAME -> CNAME is a "must not". > Cite the RFC please. 1034 says > # Domain names in RRs which point at another name should always point at > # the primary name and not the alias. > and > # domain software should not fail when presented with CNAME > # chains or loops; CNAME chains should be followed and CNAME loops > # signalled as an error. > and > #- The answer to the query, possibly preface by one or more CNAME > # RRs that specify aliases encountered on the way to an answer. > and > # Multiple levels of > # aliases should be avoided due to their lack of efficiency, but should > # not be signalled as an error. > It's fairly clear that CNAMEs to CNAMEs are discouraged, but legal. Hmmm... Looks like I have had that just about backwards (par for the course). RFC 1912 (Common DNS Errors) makes it pretty clear that other RRs should not point at CNAMEs and that would include CNAMEs pointing at CNAMEs. It quotes your same section, 3.6.2, of rfc 1034 for justifying that. ] Don't use CNAMEs in combination with RRs which point to other names ] like MX, CNAME, PTR and NS. (PTR is an exception if you want to ] implement classless in-addr delegation.) For example, this is ] strongly discouraged: ] ] podunk.xx. IN MX mailhost ] mailhostIN CNAME mary ] maryIN A 1.2.3.4 ] ] [RFC 1034] in section 3.6.2 says this should not be done, and [RFC ] 974] explicitly states that MX records shall not point to an alias ] defined by a CNAME. This results in unnecessary indirection in ] accessing the data, and DNS resolvers and servers need to work more ] to get the answer. If you really want to do this, you can accomplish ] the same thing by using a preprocessor such as m4 on your host files. That pretty explicity states that MX records should not (and, according to RFC 974, must not) point to CNAMES. ] Also, having chained records such as CNAMEs pointing to CNAMEs may ] make administration issues easier, but is known to tickle bugs in ] some resolvers that fail to check loops correctly. As a result some ] hosts may not be able to resolve such names. That's a pretty strong recommendation to NOT point CNAMEs to CNAMEs. It's not a "must not", but it points out a seeming ambiguity in RFC 1034. The very passage you quote: > # Domain names in RRs which point at another name should always point at > # the primary name and not the alias. Doesn't that say that a domain name in a RR should always point at the primary name. Doesn't that imply (and thus semi contradict the rest of that section about loops) that CNAMEs should not point to CNAMEs? That would appear to make rfc 1034 look ambiguous. Section 3.6.2 says that RRs should always point to primary names but then goes on to discuss CNAME loops and states that multiple levels of aliases should not be signaled as an error. But then we are down to semantics and the semantics of the RFCs are defined. Should and should not are recommendations, not requirements. Must and must not are requirements. On that point, I must cede the field and admit that both CNAME -> MX and CNAME -> CNAME would appear to fall under the former and not the later. But MX -> CNAME would appear to be explicitly prohibited under RFC 974. > -- > Aaron Denney > -><- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 04:11:39PM -0800, H. Peter Anvin wrote: > "Michael H. Warfield" wrote: > > > > > Please explain how there is any different between an CNAME or MX pointing > > > to an A record in a different SOA versus an MX pointing to a CNAME > > > pointing to an A record where at least one pair is local (same SOA). > > > > Ah! But now you are placing conditions on it (that at least one > > pair is local). That is the very fine distinction that makes up the > > "not quite" in the "almost" above and the difference between the "should > > not" vs the "must not" in the specifications. You basically can't qualify > > it by saying "you can do this, but only if one pair is in the same SOA". > No. My point is that potential for inefficiency is not a valid reason > for banning something outright. This should be an administrative > decision, nothing more. But, wait a minute. CNAME -> CNAME is a "must not". MX -> CNAME is a "should not". The "should not" leaves it to be implimentation dependent and not an outright ban. Sooo... I personally have no problem with Bind 9.x prohibiting an MX -> CNAME, but that's an implimentation issue. In case people have tuned in late, there have been some rather radical swings in Bind policy since Bind 4.x. Bind 8.x decided to ENFORCE (with a vengence) the character set policies dictated by RFC. This was (so they claimed) to protect poorly coded programs that were prone to blowing chunks and doing Chernobyl imitations on getting illegal characters in host names. Of course that also caused zones with underscores in names (more common than what you would think) to crap all over themselves when unsuspecting (i.e. failure to read warnings) admins upgraded. Bind 9.0 went back to the old 4.9 policy on characters (allow what can be entered and poorly coded programs are on their own) but started enforcing a requirement for a TTL directive and making the SOA TTL field the true minimum TTL that it was defined as (instead of a default like Bind 8 and 4 and previous used it as). I figured I was all set, since I, of course, had upgraded all MY zone files already. Imagine my surprise when 9.0 would not even load because OVER HALF of the 200+ zones I'm responsible for or host did NOT have the $TTL directive! It was assholes and elbows for a not so brief but really intense time while I updated those $@$%#@ zone files! You don't like the Bind enforcement of the DNS policy, bitch to the ISC bunch. They can be swayed (all too often, it appears). If enough DNS administrators really want to go against the "should not", maybe they will make it configurable (Actually, I didn't think it really outright prohibited it in the first place, but... Oh well...) There are lots of other things in the DNS that need to be killed DEAD with a stake through the heart like CNAME with other data (what is THAT suppose to mean). I run into lookups on sites with CNAMES and A records for a host! I suppose one can come up with a hierachial reason for doing such byzantine things, but do you REALLY want to? In applying the KISS principle (admitedly an oxymoron when it comes to DNS) I can see some people wanting to ban MX -> CNAME in general if, for no other reason, than to insure that you will do it only if you have really STRONG reasons for doing it. > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 04:01:30PM -0800, H. Peter Anvin wrote: > > > Wouldn't that be true for any CNAME anyway? > > That's the point... > > In other words, you do a lookup, you start with a primary lookup > > and then possibly a second lookup to resolve an MX or CNAME. It's only > > the MX that points to a CNAME that results in yet another lookup. An > > MX pointing to a CNAME is almost (almost, but not quite) as bad as a > > CNAME pointing to a CNAME. > There is no reducibility problem for MX -> CNAME, unlike the CNAME -> > CNAME case. > Please explain how there is any different between an CNAME or MX pointing > to an A record in a different SOA versus an MX pointing to a CNAME > pointing to an A record where at least one pair is local (same SOA). Ah! But now you are placing conditions on it (that at least one pair is local). That is the very fine distinction that makes up the "not quite" in the "almost" above and the difference between the "should not" vs the "must not" in the specifications. You basically can't qualify it by saying "you can do this, but only if one pair is in the same SOA". > -hpa Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 03:47:17PM -0800, H. Peter Anvin wrote: > "Michael H. Warfield" wrote: > > > > On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: > > > Followup to: <[EMAIL PROTECTED]> > > > By author:Gerhard Mack <[EMAIL PROTECTED]> > > > In newsgroup: linux.dev.kernel > > > > > > > > Thanklfully bind 9 barfs if you even try this sort of thing. > > > > > > > > > Personally I find it puzzling what's wrong with MX -> CNAME at all; it > > > seems like a useful setup without the pitfalls that either NS -> CNAME > > > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in > > > irreducible situations; CNAME -> CNAME would require a link maximum > > > count which could result in obscure breakage.) > > > > It generally forces another DNS lookup. If you do a resolve on > > a name of type=ANY it returns any MX records and A records. If you then > > do a resolve on the MX records, you then get a CNAME and then have to > > add an additional lookup for the CNAME. If you have a lot of MX records > > and not all the servers are "up" that can add up to a significant > > increase in DNS traffic. > > > Wouldn't that be true for any CNAME anyway? That's the point... In other words, you do a lookup, you start with a primary lookup and then possibly a second lookup to resolve an MX or CNAME. It's only the MX that points to a CNAME that results in yet another lookup. An MX pointing to a CNAME is almost (almost, but not quite) as bad as a CNAME pointing to a CNAME. > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Gerhard Mack <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Thanklfully bind 9 barfs if you even try this sort of thing. > > > Personally I find it puzzling what's wrong with MX -> CNAME at all; it > seems like a useful setup without the pitfalls that either NS -> CNAME > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in > irreducible situations; CNAME -> CNAME would require a link maximum > count which could result in obscure breakage.) It generally forces another DNS lookup. If you do a resolve on a name of type=ANY it returns any MX records and A records. If you then do a resolve on the MX records, you then get a CNAME and then have to add an additional lookup for the CNAME. If you have a lot of MX records and not all the servers are "up" that can add up to a significant increase in DNS traffic. > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
Followup to: [EMAIL PROTECTED]
By author:Gerhard Mack [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Thanklfully bind 9 barfs if you even try this sort of thing.
Personally I find it puzzling what's wrong with MX - CNAME at all; it
seems like a useful setup without the pitfalls that either NS - CNAME
or CNAME - CNAME can cause (NS - CNAME can trivially result in
irreducible situations; CNAME - CNAME would require a link maximum
count which could result in obscure breakage.)
It generally forces another DNS lookup. If you do a resolve on
a name of type=ANY it returns any MX records and A records. If you then
do a resolve on the MX records, you then get a CNAME and then have to
add an additional lookup for the CNAME. If you have a lot of MX records
and not all the servers are "up" that can add up to a significant
increase in DNS traffic.
-hpa
--
[EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 03:47:17PM -0800, H. Peter Anvin wrote:
"Michael H. Warfield" wrote:
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote:
Followup to: [EMAIL PROTECTED]
By author:Gerhard Mack [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Thanklfully bind 9 barfs if you even try this sort of thing.
Personally I find it puzzling what's wrong with MX - CNAME at all; it
seems like a useful setup without the pitfalls that either NS - CNAME
or CNAME - CNAME can cause (NS - CNAME can trivially result in
irreducible situations; CNAME - CNAME would require a link maximum
count which could result in obscure breakage.)
It generally forces another DNS lookup. If you do a resolve on
a name of type=ANY it returns any MX records and A records. If you then
do a resolve on the MX records, you then get a CNAME and then have to
add an additional lookup for the CNAME. If you have a lot of MX records
and not all the servers are "up" that can add up to a significant
increase in DNS traffic.
Wouldn't that be true for any CNAME anyway?
That's the point...
In other words, you do a lookup, you start with a primary lookup
and then possibly a second lookup to resolve an MX or CNAME. It's only
the MX that points to a CNAME that results in yet another lookup. An
MX pointing to a CNAME is almost (almost, but not quite) as bad as a
CNAME pointing to a CNAME.
-hpa
--
[EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 04:01:30PM -0800, H. Peter Anvin wrote: Wouldn't that be true for any CNAME anyway? That's the point... In other words, you do a lookup, you start with a primary lookup and then possibly a second lookup to resolve an MX or CNAME. It's only the MX that points to a CNAME that results in yet another lookup. An MX pointing to a CNAME is almost (almost, but not quite) as bad as a CNAME pointing to a CNAME. There is no reducibility problem for MX - CNAME, unlike the CNAME - CNAME case. Please explain how there is any different between an CNAME or MX pointing to an A record in a different SOA versus an MX pointing to a CNAME pointing to an A record where at least one pair is local (same SOA). Ah! But now you are placing conditions on it (that at least one pair is local). That is the very fine distinction that makes up the "not quite" in the "almost" above and the difference between the "should not" vs the "must not" in the specifications. You basically can't qualify it by saying "you can do this, but only if one pair is in the same SOA". -hpa Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 04:11:39PM -0800, H. Peter Anvin wrote: "Michael H. Warfield" wrote: Please explain how there is any different between an CNAME or MX pointing to an A record in a different SOA versus an MX pointing to a CNAME pointing to an A record where at least one pair is local (same SOA). Ah! But now you are placing conditions on it (that at least one pair is local). That is the very fine distinction that makes up the "not quite" in the "almost" above and the difference between the "should not" vs the "must not" in the specifications. You basically can't qualify it by saying "you can do this, but only if one pair is in the same SOA". No. My point is that potential for inefficiency is not a valid reason for banning something outright. This should be an administrative decision, nothing more. But, wait a minute. CNAME - CNAME is a "must not". MX - CNAME is a "should not". The "should not" leaves it to be implimentation dependent and not an outright ban. Sooo... I personally have no problem with Bind 9.x prohibiting an MX - CNAME, but that's an implimentation issue. In case people have tuned in late, there have been some rather radical swings in Bind policy since Bind 4.x. Bind 8.x decided to ENFORCE (with a vengence) the character set policies dictated by RFC. This was (so they claimed) to protect poorly coded programs that were prone to blowing chunks and doing Chernobyl imitations on getting illegal characters in host names. Of course that also caused zones with underscores in names (more common than what you would think) to crap all over themselves when unsuspecting (i.e. failure to read warnings) admins upgraded. Bind 9.0 went back to the old 4.9 policy on characters (allow what can be entered and poorly coded programs are on their own) but started enforcing a requirement for a TTL directive and making the SOA TTL field the true minimum TTL that it was defined as (instead of a default like Bind 8 and 4 and previous used it as). I figured I was all set, since I, of course, had upgraded all MY zone files already. Imagine my surprise when 9.0 would not even load because OVER HALF of the 200+ zones I'm responsible for or host did NOT have the $TTL directive! It was assholes and elbows for a not so brief but really intense time while I updated those $@$%#@ zone files! You don't like the Bind enforcement of the DNS policy, bitch to the ISC bunch. They can be swayed (all too often, it appears). If enough DNS administrators really want to go against the "should not", maybe they will make it configurable (Actually, I didn't think it really outright prohibited it in the first place, but... Oh well...) There are lots of other things in the DNS that need to be killed DEAD with a stake through the heart like CNAME with other data (what is THAT suppose to mean). I run into lookups on sites with CNAMES and A records for a host! I suppose one can come up with a hierachial reason for doing such byzantine things, but do you REALLY want to? In applying the KISS principle (admitedly an oxymoron when it comes to DNS) I can see some people wanting to ban MX - CNAME in general if, for no other reason, than to insure that you will do it only if you have really STRONG reasons for doing it. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Fri, Feb 09, 2001 at 01:50:04AM +, Aaron Denney wrote:
Michael H. Warfield [EMAIL PROTECTED] wrote:
But, wait a minute. CNAME - CNAME is a "must not".
Cite the RFC please. 1034 says
# Domain names in RRs which point at another name should always point at
# the primary name and not the alias.
and
# domain software should not fail when presented with CNAME
# chains or loops; CNAME chains should be followed and CNAME loops
# signalled as an error.
and
#- The answer to the query, possibly preface by one or more CNAME
# RRs that specify aliases encountered on the way to an answer.
and
# Multiple levels of
# aliases should be avoided due to their lack of efficiency, but should
# not be signalled as an error.
It's fairly clear that CNAMEs to CNAMEs are discouraged, but legal.
Hmmm... Looks like I have had that just about backwards (par for
the course). RFC 1912 (Common DNS Errors) makes it pretty clear that
other RRs should not point at CNAMEs and that would include CNAMEs
pointing at CNAMEs. It quotes your same section, 3.6.2, of rfc 1034
for justifying that.
] Don't use CNAMEs in combination with RRs which point to other names
] like MX, CNAME, PTR and NS. (PTR is an exception if you want to
] implement classless in-addr delegation.) For example, this is
] strongly discouraged:
]
] podunk.xx. IN MX mailhost
] mailhostIN CNAME mary
] maryIN A 1.2.3.4
]
] [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
] 974] explicitly states that MX records shall not point to an alias
] defined by a CNAME. This results in unnecessary indirection in
] accessing the data, and DNS resolvers and servers need to work more
] to get the answer. If you really want to do this, you can accomplish
] the same thing by using a preprocessor such as m4 on your host files.
That pretty explicity states that MX records should not (and,
according to RFC 974, must not) point to CNAMES.
] Also, having chained records such as CNAMEs pointing to CNAMEs may
] make administration issues easier, but is known to tickle bugs in
] some resolvers that fail to check loops correctly. As a result some
] hosts may not be able to resolve such names.
That's a pretty strong recommendation to NOT point CNAMEs to
CNAMEs. It's not a "must not", but it points out a seeming ambiguity in
RFC 1034. The very passage you quote:
# Domain names in RRs which point at another name should always point at
# the primary name and not the alias.
Doesn't that say that a domain name in a RR should always point
at the primary name. Doesn't that imply (and thus semi contradict the
rest of that section about loops) that CNAMEs should not point to CNAMEs?
That would appear to make rfc 1034 look ambiguous. Section
3.6.2 says that RRs should always point to primary names but then
goes on to discuss CNAME loops and states that multiple levels of
aliases should not be signaled as an error.
But then we are down to semantics and the semantics of the RFCs
are defined. Should and should not are recommendations, not requirements.
Must and must not are requirements. On that point, I must cede the field
and admit that both CNAME - MX and CNAME - CNAME would appear to fall
under the former and not the later. But MX - CNAME would appear to be
explicitly prohibited under RFC 974.
--
Aaron Denney
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Secure Linux
On Tue, Jan 30, 2001 at 06:47:18PM +, Dale Amon wrote: > Has anyone else signed up on the NSA's secure Linux > discussion list? The idea of NSA backing the development > of a secure GPL'd linux is one I find intriguing. 1) It is not "Secure Linux", it is "Security Enhanced Linux". It's a proof of concept of adding type enforcement to the Linux kernel and looks very promising. > However I have only seen one posting. Is there anyone > "real" involved with it? Why not join the selinux mailing list and find out? [EMAIL PROTECTED] Seems to be a pretty active list. > -- > -- > Use Linux: A computerDale Amon, CEO/MD > is a terrible thing Village Networking Ltd > to waste.Belfast, Northern Ireland > -- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
On Wed, Jan 31, 2001 at 06:02:17PM +, Alan Cox wrote: > > No. ECN is essential to the continued stability of the Internet. Without > > probabilistic queuing (i.e. RED) and ECN the Internet will continue to have > > retransmit synchronization and once congested stay congested until people get > > frustrated and give it up for a little bit. > Arguably so. In theory a vindictive probabilistic queueing is sufficient > (do RED but then drop -every- frame from the same route as the packet chosen > from the queue) THAT actually sounds very similar to what some ATM switches are doing when congestion results in lost cells in an IP datagram. Some time ago, a buddy up at Sandia National Laboratories was explaining the problem with congestion and IP over ATM. Once the congestion level reachs a certain point, the probability of the ATM network dropping a single cell out of the many cells comprising a complete IP datagram exceeds unity. All the transmitted cells, however, are contributing to the congestion. The datagram eventually gets retried and adds even more to the congestion. Net result is that once you pass this congestion threshold, IP throughput completely collapses and retries keep it there until higher layers fail. The answer for some intelligent ATM switches is to recognize the higher layer IP traffic and, when dropping an ATM cell in the middle of an IP datagram, to drop ALL the cells in a datagram if any of the cells are going to be dropped. That way the remaining cells are not contributing to the congestion when the entire IP datagram is going to be retransmitted anyways. Purists MIGHT argue that this is a layering violation, but it would seem to be a good one. :-/ You could call it vindictive, or maybe congestion with extreme prejudice... :-) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
On Wed, Jan 31, 2001 at 06:02:17PM +, Alan Cox wrote: No. ECN is essential to the continued stability of the Internet. Without probabilistic queuing (i.e. RED) and ECN the Internet will continue to have retransmit synchronization and once congested stay congested until people get frustrated and give it up for a little bit. Arguably so. In theory a vindictive probabilistic queueing is sufficient (do RED but then drop -every- frame from the same route as the packet chosen from the queue) THAT actually sounds very similar to what some ATM switches are doing when congestion results in lost cells in an IP datagram. Some time ago, a buddy up at Sandia National Laboratories was explaining the problem with congestion and IP over ATM. Once the congestion level reachs a certain point, the probability of the ATM network dropping a single cell out of the many cells comprising a complete IP datagram exceeds unity. All the transmitted cells, however, are contributing to the congestion. The datagram eventually gets retried and adds even more to the congestion. Net result is that once you pass this congestion threshold, IP throughput completely collapses and retries keep it there until higher layers fail. The answer for some intelligent ATM switches is to recognize the higher layer IP traffic and, when dropping an ATM cell in the middle of an IP datagram, to drop ALL the cells in a datagram if any of the cells are going to be dropped. That way the remaining cells are not contributing to the congestion when the entire IP datagram is going to be retransmitted anyways. Purists MIGHT argue that this is a layering violation, but it would seem to be a good one. :-/ You could call it vindictive, or maybe congestion with extreme prejudice... :-) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Secure Linux
On Tue, Jan 30, 2001 at 06:47:18PM +, Dale Amon wrote: Has anyone else signed up on the NSA's secure Linux discussion list? The idea of NSA backing the development of a secure GPL'd linux is one I find intriguing. 1) It is not "Secure Linux", it is "Security Enhanced Linux". It's a proof of concept of adding type enforcement to the Linux kernel and looks very promising. However I have only seen one posting. Is there anyone "real" involved with it? Why not join the selinux mailing list and find out? [EMAIL PROTECTED] Seems to be a pretty active list. -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Ok, someone is trying to be funny
On Fri, Feb 02, 2001 at 03:36:46PM -0800, David S. Miller wrote: > Ok, it seems somebody is running a cron script or similar > to keep resubscribing that [EMAIL PROTECTED] address > to linux-kernel. So block them using the /etc/mail/access database for sendmail and do it with a "451" error code. The data will back up on their mail server and start clogging their mail spool till they get a clue. (Ok... 5 day expiration on the messages, but ITMT, they get several warning and error messages from each too). > So if you see the "moderation" message back from a posting > you make to linux-kernel, please dont' report it to us here > at vger.kernel.org, we know about it. > Later, > David S. Miller > [EMAIL PROTECTED] Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Ok, someone is trying to be funny
On Fri, Feb 02, 2001 at 03:36:46PM -0800, David S. Miller wrote:
Ok, it seems somebody is running a cron script or similar
to keep resubscribing that [EMAIL PROTECTED] address
to linux-kernel.
So block them using the /etc/mail/access database for sendmail
and do it with a "451" error code. The data will back up on their
mail server and start clogging their mail spool till they get a clue.
(Ok... 5 day expiration on the messages, but ITMT, they get several
warning and error messages from each too).
So if you see the "moderation" message back from a posting
you make to linux-kernel, please dont' report it to us here
at vger.kernel.org, we know about it.
Later,
David S. Miller
[EMAIL PROTECTED]
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
Damn... So much for typing too fast... Screwed it up...
On Sun, Jan 28, 2001 at 07:59:47PM -0500, Michael H. Warfield wrote:
> On Sun, Jan 28, 2001 at 04:55:51PM -0800, David D.W. Downey wrote:
> > Hi Linus,
> > Sorry to bother you. I'm trying to find where you uploaded
> > linux-2.4.1-pre11.
> > I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the
> > /pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/
> > directories. Is it somewhere different?
> Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz
Patch was in /pub/linux/kernel/test/patch-2.4.1-pre11.gz
Cut and paste screwup. Sorry.
[...]
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
On Sun, Jan 28, 2001 at 04:55:51PM -0800, David D.W. Downey wrote:
> Hi Linus,
> Sorry to bother you. I'm trying to find where you uploaded
> linux-2.4.1-pre11.
> I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the
> /pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/
> directories. Is it somewhere different?
Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz
> Also, Alan, I grabbed your patch-2.4.0-ac11.gz file from your directory on
> ftp.kernel.org. Does this contain the updated VIA IDE support that Linus
> was talking about in the 2.4.1-pre11?
> I'm thinking either kernel.org hasn't posted the 2.4.1-pre11 or I totally
> misunderstand the directory layout on kernel.org.
Close...
> A URL to the right patch or, preferably, full source for 2.4.1-pre11 would
> be great.
> Thanks,
> David D.W. Downey
[...]
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Support for 802.11 cards?
On Sun, Jan 28, 2001 at 05:07:33PM -0500, John Jasen wrote:
> On Sun, 28 Jan 2001, Mike Pontillo wrote:
> > I was wondering what 802.11 PCI cards anyone knows of that run
> > under Linux-2.4. (or 2.2 for that matter)
> I _think_ a good many of the 802.11 wireless ISA and PCI cards are just
> bus to PCMCIA adapters, so it would be a question of whether or not the
> PCMCIA card is supported and if the bridge is supported.
Last I knew (straight from the Lucent people), the ISA bridge
card worked fine and the PCI card did NOT work at all. I've since
confirmed that, first hand, myself (I currently have the ISA bridge in
operation) on the 2.2 kernels. The ISA bridge also works on the 2.4
kernels but I have not retested the PCI bridge on 2.4. The Lucent
people claim that the Linux pcmcia people are aware of the problem.
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Kernel Janitor's TODO list
On Sun, Jan 28, 2001 at 03:20:18PM +, David Woodhouse wrote: > [EMAIL PROTECTED] said: > > Please send additions and corrections to me and I'll try to keep it > > updated. > Anything which uses sleep_on() has a 90% chance of being broken. Fix > them all, because we want to remove sleep_on() and friends in 2.5. And friends meaning "interruptible_sleep_on"? Great... I've got a driver with about a half a dozen of them. Point me at the Doco to fix please? > -- > dwmw2 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: hotmail not dealing with ECN
On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote: > On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote: > ... > > An attack against an Xray system is much more likely to come from inside the > > companies network. > ... > We are not talking about attacks here, we are talking about undefined > behaviour when (perhaps poorly designed) systems encounter network > packages that use new or experimental features: I have seen MRI scanners > panic when they received SNMP queries and SNMP has been around for ages! Couple of years ago I did a security advisory on OS/9 (the Microware OS that was originally designed for 6809 processors). It had become quite popular for embedded controllers. I think at the time it was ranked one of the top three embedded controller operating systems and was used in a large number of Allen Bradley controllers. Read that last statement as saying that it was in a GOD AWFULL number of HVAC controllers and factory automation controllers around the entire world. We stumbled onto a flaw in the protocol stacks in OS/9 and it couldn't handle being hit with an ICMP redirect. The incoming stack didn't properly recognize it and created some weird state in the outgoing stack. The next time the controller tried to transmit something, the controller hung leaving whatever it was controlling in what ever position it was in, no matter what the consequences. This was "discovered" the hard way at a site where the network people had not even realized that all of these controllers were connected to the main corporate network. Envision hundreds of controllers suddenly freezing and an entire plant rapidly grinding to a complete halt. My contact at Microware told me that they never anticipated having those controllers hooked up to a general purpose network and OS/9 was designed for such a small footprint (Hey, I had a multitasking, multiuser, dial-in system running on a RadioShack CoCo with 64K of memory running OS/9) that they had no room for handling ICMP redirects so they hadn't coded it into the stack. Multiple mistakes and assumptions resulted in a security advisory warning about potential threats to human health and safety. They were having a bad day... Especially when CNN called them. :-/ (They had been notified over 6 months prior to the publication of the advisory, BTW...) That advisory concluded to isolate all embedded controllers to insulated subnets and configure all routers to refuse to pass ICMP redirect packets. Anyone want to take bets if it's been done to any great extent? It will take some factory being knocked on it's ass and making CNN, and even then most people won't take action because most of the admins don't know what's on their networks in those environments. Upgrading a lot of these old controllers also meant physically removing and replacing EPROMS. (One claim to fame for OS/9 is that it was totally PIC and could be copied straight into EPROM and run equally well from EPROM or RAM at arbitrary addresses.) That's even assuming you knew where all your controllers were and how to get to them! So... Yeah... I can understand what can happen when unknown packets reach devices that were not designed to handle them. Bad Juju... And embedded controllers are a hell of a lot more plentyful than X-Ray machines. > Yours, > Dominik Kubla > -- > A lovely thing to see: Kobayashi Issa > through the paper window's holes (1763-1828) > the galaxy. [taken from: David Brin - Sundiver] Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: hotmail not dealing with ECN
On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote: On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote: ... An attack against an Xray system is much more likely to come from inside the companies network. ... We are not talking about attacks here, we are talking about undefined behaviour when (perhaps poorly designed) systems encounter network packages that use new or experimental features: I have seen MRI scanners panic when they received SNMP queries and SNMP has been around for ages! Couple of years ago I did a security advisory on OS/9 (the Microware OS that was originally designed for 6809 processors). It had become quite popular for embedded controllers. I think at the time it was ranked one of the top three embedded controller operating systems and was used in a large number of Allen Bradley controllers. Read that last statement as saying that it was in a GOD AWFULL number of HVAC controllers and factory automation controllers around the entire world. We stumbled onto a flaw in the protocol stacks in OS/9 and it couldn't handle being hit with an ICMP redirect. The incoming stack didn't properly recognize it and created some weird state in the outgoing stack. The next time the controller tried to transmit something, the controller hung leaving whatever it was controlling in what ever position it was in, no matter what the consequences. This was "discovered" the hard way at a site where the network people had not even realized that all of these controllers were connected to the main corporate network. Envision hundreds of controllers suddenly freezing and an entire plant rapidly grinding to a complete halt. My contact at Microware told me that they never anticipated having those controllers hooked up to a general purpose network and OS/9 was designed for such a small footprint (Hey, I had a multitasking, multiuser, dial-in system running on a RadioShack CoCo with 64K of memory running OS/9) that they had no room for handling ICMP redirects so they hadn't coded it into the stack. Multiple mistakes and assumptions resulted in a security advisory warning about potential threats to human health and safety. They were having a bad day... Especially when CNN called them. :-/ (They had been notified over 6 months prior to the publication of the advisory, BTW...) That advisory concluded to isolate all embedded controllers to insulated subnets and configure all routers to refuse to pass ICMP redirect packets. Anyone want to take bets if it's been done to any great extent? It will take some factory being knocked on it's ass and making CNN, and even then most people won't take action because most of the admins don't know what's on their networks in those environments. Upgrading a lot of these old controllers also meant physically removing and replacing EPROMS. (One claim to fame for OS/9 is that it was totally PIC and could be copied straight into EPROM and run equally well from EPROM or RAM at arbitrary addresses.) That's even assuming you knew where all your controllers were and how to get to them! So... Yeah... I can understand what can happen when unknown packets reach devices that were not designed to handle them. Bad Juju... And embedded controllers are a hell of a lot more plentyful than X-Ray machines. Yours, Dominik Kubla -- A lovely thing to see: Kobayashi Issa through the paper window's holes (1763-1828) the galaxy. [taken from: David Brin - Sundiver] Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Kernel Janitor's TODO list
On Sun, Jan 28, 2001 at 03:20:18PM +, David Woodhouse wrote: [EMAIL PROTECTED] said: Please send additions and corrections to me and I'll try to keep it updated. Anything which uses sleep_on() has a 90% chance of being broken. Fix them all, because we want to remove sleep_on() and friends in 2.5. And friends meaning "interruptible_sleep_on"? Great... I've got a driver with about a half a dozen of them. Point me at the Doco to fix please? -- dwmw2 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Support for 802.11 cards?
On Sun, Jan 28, 2001 at 05:07:33PM -0500, John Jasen wrote: On Sun, 28 Jan 2001, Mike Pontillo wrote: I was wondering what 802.11 PCI cards anyone knows of that run under Linux-2.4. (or 2.2 for that matter) I _think_ a good many of the 802.11 wireless ISA and PCI cards are just bus to PCMCIA adapters, so it would be a question of whether or not the PCMCIA card is supported and if the bridge is supported. Last I knew (straight from the Lucent people), the ISA bridge card worked fine and the PCI card did NOT work at all. I've since confirmed that, first hand, myself (I currently have the ISA bridge in operation) on the 2.2 kernels. The ISA bridge also works on the 2.4 kernels but I have not retested the PCI bridge on 2.4. The Lucent people claim that the Linux pcmcia people are aware of the problem. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
On Sun, Jan 28, 2001 at 04:55:51PM -0800, David D.W. Downey wrote: Hi Linus, Sorry to bother you. I'm trying to find where you uploaded linux-2.4.1-pre11. I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the /pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/ directories. Is it somewhere different? Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz Also, Alan, I grabbed your patch-2.4.0-ac11.gz file from your directory on ftp.kernel.org. Does this contain the updated VIA IDE support that Linus was talking about in the 2.4.1-pre11? I'm thinking either kernel.org hasn't posted the 2.4.1-pre11 or I totally misunderstand the directory layout on kernel.org. Close... A URL to the right patch or, preferably, full source for 2.4.1-pre11 would be great. Thanks, David D.W. Downey [...] Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
Damn... So much for typing too fast... Screwed it up... On Sun, Jan 28, 2001 at 07:59:47PM -0500, Michael H. Warfield wrote: On Sun, Jan 28, 2001 at 04:55:51PM -0800, David D.W. Downey wrote: Hi Linus, Sorry to bother you. I'm trying to find where you uploaded linux-2.4.1-pre11. I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the /pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/ directories. Is it somewhere different? Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz Patch was in /pub/linux/kernel/test/patch-2.4.1-pre11.gz Cut and paste screwup. Sorry. [...] Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotmail not dealing with ECN
On Fri, Jan 26, 2001 at 01:52:26PM -0800, Stuart Lynne wrote: > In article <[EMAIL PROTECTED]>, > James Sutherland <[EMAIL PROTECTED]> wrote: > >On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote: > >Except you can't retry without ECN, because DaveM wants to do a Microsoft > >and force ECN on everyone, whether they like it or not. If ECN is so > No, he just wants them to ignore it like they are supposed to do if > they don't know what it is. > >wonderful, why doesn't anybody actually WANT to use it anyway? > Because they are stupid and don't want to take the time and energy > to upgrade their systems. > Most ISP's have the generic rule, if it ain't broke, don't fuck with it. > Even the mighty microsoft learned just two days ago what happens if you > make mistakes changing routing information. No... Microsoft learned, just two days ago, something that has been part of best practices for over 15 years. Do NOT put all of your DNS servers on the same network! The technical error may have triggered the meltdown but if they had distributed their DNS the way they were suppose to, it would have NOT taken them totally out. It wasn't the technician's mistake. It was the single point of failure (and subsequently the single point of attack). He just triggered it. > -- > __O > Lineo - For Emedded Linux Solutions _-\<,_ > PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 > Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotmail not dealing with ECN
On Fri, Jan 26, 2001 at 01:52:26PM -0800, Stuart Lynne wrote: In article [EMAIL PROTECTED], James Sutherland [EMAIL PROTECTED] wrote: On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote: Except you can't retry without ECN, because DaveM wants to do a Microsoft and force ECN on everyone, whether they like it or not. If ECN is so No, he just wants them to ignore it like they are supposed to do if they don't know what it is. wonderful, why doesn't anybody actually WANT to use it anyway? Because they are stupid and don't want to take the time and energy to upgrade their systems. Most ISP's have the generic rule, if it ain't broke, don't fuck with it. Even the mighty microsoft learned just two days ago what happens if you make mistakes changing routing information. No... Microsoft learned, just two days ago, something that has been part of best practices for over 15 years. Do NOT put all of your DNS servers on the same network! The technical error may have triggered the meltdown but if they had distributed their DNS the way they were suppose to, it would have NOT taken them totally out. It wasn't the technician's mistake. It was the single point of failure (and subsequently the single point of attack). He just triggered it. -- __O Lineo - For Emedded Linux Solutions _-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.fireplug.net604-461-7532 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Which Bind version..
On Mon, Jan 08, 2001 at 12:56:37PM +0500, Mike wrote:
> Hi!!
> I wanna install Bind on my DNS. Which Bind version is most stabel and
> secure.
9.0.1 is the latest release in the 9.x series and if you are
interested in "SecureDNS", that's the way to go. I'm currently running
9.1.0beta2, and it seems rock solid to me. There is also 8.2.2P7 if
you want to stick the the older 8.x series, but I certainly wouldn't
if I were setting up a new DNS server. The 4.x series is totally
deprecated at this point. Personally, I wouldn't use anything less
than 9.0.1 and I currently support over 100 domains on my servers
(my partner runs a hosting service).
> Regards,
> Nauman Ansari
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Which Bind version..
On Mon, Jan 08, 2001 at 12:56:37PM +0500, Mike wrote: Hi!! I wanna install Bind on my DNS. Which Bind version is most stabel and secure. 9.0.1 is the latest release in the 9.x series and if you are interested in "SecureDNS", that's the way to go. I'm currently running 9.1.0beta2, and it seems rock solid to me. There is also 8.2.2P7 if you want to stick the the older 8.x series, but I certainly wouldn't if I were setting up a new DNS server. The 4.x series is totally deprecated at this point. Personally, I wouldn't use anything less than 9.0.1 and I currently support over 100 domains on my servers (my partner runs a hosting service). Regards, Nauman Ansari Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 10:30:14PM -0500, Gregory Maxwell wrote:
> On Sun, Jan 07, 2001 at 08:22:28PM -0500, Michael H. Warfield wrote:
> > I already run several sugarplum sites with teergrubes. I also use
> > various blackhole lists and take other action against spammers, including
> > blocking entire rogue domains. If that rogue domain happens to be a two
> > letter TLD, so be it. If it gets bad enough, maybe they'll fix it.
> You are suggesting that it is acceptable to implement technological
> barriers to a minority expressing speech that is unacceptable to the
> majority. This is not acceptable.
No... I'm say that their right to free speech does not trump
my right to not have to listen to it or download it and I determine
the criterion, they don't. I have, in my right to free speech, the
right to say screw off, I don't want to hear it.
> When you subscript your mailbox to list of 'spammers' to avoid associating
> with them, with the knowledge that you may lose some valuable mail, that is
> fine.
Excuse me??? Clue alert! I'm not subscribing anything to any
spam mailbox. I'm not doing jack shit to subscribe myself to anything
to do with them. I am leaving bait around for them to screw themselves,
but I certainly have the free speech right to do that, now don't I?
I don't go to them and say "subscribe all these addresses". I don't
say to them, send E-Mail here. They are trespassing on my systems,
clearly stepping over well delineated boundries.
I'm really lost by your reasoning on this one. "Subscribing my
mailbox to a list of 'spammers' to avoid associating with them, with the
knowledge that you loose some valuable mail" makes absolutely no sense
what so ever. The legitimate mail I may or may not loose has no bearing
on the sugarplum or teergrube systems (which is what I'm assuming that
you are elluding to).
> The situation is similar to not visiting a gay bar if you don't like
> homosexual people. However, that is not what you are doing blocking whole
> countries. That is like building concrete barriers around cites to punish
> them for not oppressing their own minority citizen ("I'm going to block your
> whole country until you outlaw this class of speech I find offensive").
Tough... I find the speech offensive, I don't have to listen
to it. If I find that the level of offensive speech from a particular
source exceeds all value, then I have the right to block it. They don't
like it, they have a right to change. Like I said... I don't take
active action against them. They have to come to me. They come to
my web site and step over my limits and contact my systems. I'm not
going to them.
> Spam is not good, but destroying freedom is worse. I suggest that every
> person who is eager to use oppressive technological measures to stop spammers
> please consider the potential wider consequences.
Destroying my freedom is just as bad. I have the freedom to
choose and I have the freedom not to be plagued by the vermin who have
harvested my addresses and are using them in a way that violates my
acceptable use on my addresses.
> Today the majority thinks spam is wrong, today you are a part of the
> majority. The Internet should always avoid the tyranny of the masses, even
> when it's operators are a part of the 'mass' today. Tomorrow the issue will
> not be spam, and you might not be in the majority.
Not a problem. Won't be the first time and won't be the last time.
I deal and so shall they.
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 06:31:11PM -0700, Matt Beland wrote: > Thereby killing how many hundreds of innocent people? China doesn't much > believe in fining minor offenders, remember. > You don't like Spam? Join the club. Blacklisting any domain - ANY domain - > for spamming, unless you can absolutely prove that no legitimate email has > ever been sent from that server, is completely unacceptable. You complain > about the wasted time and bandwidth caused by Spam messages - how much time > do you waste every year blocking legitimate messages? Not nearly as much time wasted as the time and bandwidth that gets wasted for doing nothing. The problem is bad enough. Letting them run wild will make the cesspool stink even worse. The sites that get blocked are misconfigured and need to be fixed. They're just getting a little more incentive. Most of the spam I reject gets rejected before the data transfered (blackhole tagged). That preserves my resources. Spot checking indicates that I'm loosing very little legitimate mail. Example... By using DULS RBL, I block the majority of directed mail from dialup sites. Spot checking reveals that my kill ratio is better than 100:1 on that (100 spam to less than 1 legit). Only site I have ever needed to code an exception for was Bruce Peren's Map site when he had to move it to a personal connection. (BTW... I spot check by running some sites configured to drop rejected mail in spam cans and occasionally do this on my main server. I also check logs for legit traffic being rejected.) Anyone who hits one of my teergrubes has absolutely no legitimate business what so ever! There is not a single legitimate address on those tarpits. Oh! The poor sucky spammer got stuck talking to a few thousand addresses on a machine that takes three minutes to tell him "OK". Sorry, no tears... They get exactly what they deserve. They got the addresses by violating the robots.txt rules and harvesting poisoned pages. That's the only way they will find those addresses. Tough. BTW... I'm seeing several spam address harvestors chewing on my sugarplums every week. It's getting close to seeing more spam address harvestors than seeing legitimate search engines through my web sites. Mind you... What I do is actually pretty minor. The potential for real damage really exists. Several anti-spam sites jokingly suggest that rejection codes should be "4xx" codes instead of "5xx" codes. Think about that for a second... They haven't transferred any data to you but you tell them to hold that data and try back later (4xx codes signify temporary errors that may be retried). So that data sits on their system until their final retries time out several days (5 days typical) later. Now... Take that and take advantage of the old "percent hack" that thousands of servers around the net still support (and are vulnerable open relays in and of their own right). Send a message to each of those servers pecent hacking a huge message at the chump you want to target with a final address of a system that blocks him with a 4xx code. With little effort you can totally shut down his mail spool and backup mail onto the percent hackable servers. Even if he manually cleans his spool, he's got another shit load or two waiting for him. Sites which permit open relaying are vulnerable to the 4xx code attacks. They have an open death trap DoS security vulnerability on them. The fact that we don't take advantage of it, means we're the nice guys. We only give them 5xx codes and tell them to go away... I have the right to decide, based on what ever criterion I chose, to accept or reject E-Mail. For the sites that I administer for a large E-Mail base, that needs to be in accordance with the established policies. In most cases, I have a hard time coming up with rules strict enough to adhere to those policies while still keeping the mail flowing. The owners of those sites have a right to dictate those policies. Not the senders. > Matt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 07:27:45PM -0500, Gregory Maxwell wrote: > On Sun, Jan 07, 2001 at 06:16:15PM -0500, Michael H. Warfield wrote: > > 99% of mine is from China (either *.cn or 163.com or some other > > numbering .com or .net. The .org is frowned upon in China - the TLD of > > protestors and disidents). Half of what's left comes from either .kr > > or .br. I'm fully in favor of an Internet Death Penalty against those > > TLD's and associated domains till they clean up their acts. > Yea! > Next we'll take care of those subversive linux bastards that clog up our big > pipes with their communist kernel downloads! > Unsolicited commercial email is a problem. However, many of the 'solutions' > are worse. Search for teergrube for a less subvertible aid. I already run several sugarplum sites with teergrubes. I also use various blackhole lists and take other action against spammers, including blocking entire rogue domains. If that rogue domain happens to be a two letter TLD, so be it. If it gets bad enough, maybe they'll fix it. > You can pile on technological 'fixes' as much as you want, but no > technological measure that does not totally oppress free use of the Internet > will be affective. Education is the only solution, spam will continue as > long as it is profitable. Actually, the most fun with the Chinese is to take advantage of their "four horsemen of the Infocalypse". Ours (in the US and many other western countries) is "Drug Dealing", "Money Laundering", "Pedophiles", and "Terrorists". In China it's "Taiwan", "Tibet", "Dissidents", and "Pornography". In discussing the Spam problem with some Chinese officials in Beijing back in June of last year, they were really ho hum about the whole thing till I mentioned that a lot of the spam being relayed out of the Phillipeans through Chinese sites was promoting pornography. That got some people sitting up real tight. They didn't care that their pipeline in and out of China was oversubscribed by an order of magnitude and spammers were clogging it with trash, but they damn well did care if that trash had anything to do with pornography. I've heard some people suggest that they mail message back to spam sites in China thanking them for their mail and including some propaganda on Taiwan or Tibet. Maybe some Falun Gong literature would be nice... Attack a social problem by turning another social problem loose... :-) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: .br blacklisted ?
On Mon, Jan 08, 2001 at 12:03:19AM +0100, Pedro M. Rodrigues wrote: >Lucky b*st*rd! ;-) My spam is mostly from USA. Just deleted 78 > of those, and only 7 seemed to be from abroad. I wish i could block > .com ... ;-) 99% of mine is from China (either *.cn or 163.com or some other numbering .com or .net. The .org is frowned upon in China - the TLD of protestors and disidents). Half of what's left comes from either .kr or .br. I'm fully in favor of an Internet Death Penalty against those TLD's and associated domains till they clean up their acts. > Pedro > On 7 Jan 2001, at 17:53, John O'Donnell wrote: > > Only on my company's e-mail server. My company typically gets "zero" > > emails from outside the US. If I get a piece of spam (sorry they are > > typically from outside the US), I just block the entire .com.br > > domain. I get far less SPAM now! I cannot express how much I loathe > > SPAM! I have taken this one in particular out just for you :-) I > > am the only one at my company really active on the internet.. > > apologies Johnny O Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: .br blacklisted ?
On Mon, Jan 08, 2001 at 12:03:19AM +0100, Pedro M. Rodrigues wrote: Lucky b*st*rd! ;-) My spam is mostly from USA. Just deleted 78 of those, and only 7 seemed to be from abroad. I wish i could block .com ... ;-) 99% of mine is from China (either *.cn or 163.com or some other numbering .com or .net. The .org is frowned upon in China - the TLD of protestors and disidents). Half of what's left comes from either .kr or .br. I'm fully in favor of an Internet Death Penalty against those TLD's and associated domains till they clean up their acts. Pedro On 7 Jan 2001, at 17:53, John O'Donnell wrote: Only on my company's e-mail server. My company typically gets "zero" emails from outside the US. If I get a piece of spam (sorry they are typically from outside the US), I just block the entire .com.br domain. I get far less SPAM now! I cannot express how much I loathe SPAM! I have taken this one in particular out just for you :-) I am the only one at my company really active on the internet.. apologies Johnny O Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 07:27:45PM -0500, Gregory Maxwell wrote: On Sun, Jan 07, 2001 at 06:16:15PM -0500, Michael H. Warfield wrote: 99% of mine is from China (either *.cn or 163.com or some other numbering .com or .net. The .org is frowned upon in China - the TLD of protestors and disidents). Half of what's left comes from either .kr or .br. I'm fully in favor of an Internet Death Penalty against those TLD's and associated domains till they clean up their acts. Yea! Next we'll take care of those subversive linux bastards that clog up our big pipes with their communist kernel downloads! Unsolicited commercial email is a problem. However, many of the 'solutions' are worse. Search for teergrube for a less subvertible aid. I already run several sugarplum sites with teergrubes. I also use various blackhole lists and take other action against spammers, including blocking entire rogue domains. If that rogue domain happens to be a two letter TLD, so be it. If it gets bad enough, maybe they'll fix it. You can pile on technological 'fixes' as much as you want, but no technological measure that does not totally oppress free use of the Internet will be affective. Education is the only solution, spam will continue as long as it is profitable. Actually, the most fun with the Chinese is to take advantage of their "four horsemen of the Infocalypse". Ours (in the US and many other western countries) is "Drug Dealing", "Money Laundering", "Pedophiles", and "Terrorists". In China it's "Taiwan", "Tibet", "Dissidents", and "Pornography". In discussing the Spam problem with some Chinese officials in Beijing back in June of last year, they were really ho hum about the whole thing till I mentioned that a lot of the spam being relayed out of the Phillipeans through Chinese sites was promoting pornography. That got some people sitting up real tight. They didn't care that their pipeline in and out of China was oversubscribed by an order of magnitude and spammers were clogging it with trash, but they damn well did care if that trash had anything to do with pornography. I've heard some people suggest that they mail message back to spam sites in China thanking them for their mail and including some propaganda on Taiwan or Tibet. Maybe some Falun Gong literature would be nice... Attack a social problem by turning another social problem loose... :-) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 06:31:11PM -0700, Matt Beland wrote: Thereby killing how many hundreds of innocent people? China doesn't much believe in fining minor offenders, remember. You don't like Spam? Join the club. Blacklisting any domain - ANY domain - for spamming, unless you can absolutely prove that no legitimate email has ever been sent from that server, is completely unacceptable. You complain about the wasted time and bandwidth caused by Spam messages - how much time do you waste every year blocking legitimate messages? Not nearly as much time wasted as the time and bandwidth that gets wasted for doing nothing. The problem is bad enough. Letting them run wild will make the cesspool stink even worse. The sites that get blocked are misconfigured and need to be fixed. They're just getting a little more incentive. Most of the spam I reject gets rejected before the data transfered (blackhole tagged). That preserves my resources. Spot checking indicates that I'm loosing very little legitimate mail. Example... By using DULS RBL, I block the majority of directed mail from dialup sites. Spot checking reveals that my kill ratio is better than 100:1 on that (100 spam to less than 1 legit). Only site I have ever needed to code an exception for was Bruce Peren's Map site when he had to move it to a personal connection. (BTW... I spot check by running some sites configured to drop rejected mail in spam cans and occasionally do this on my main server. I also check logs for legit traffic being rejected.) Anyone who hits one of my teergrubes has absolutely no legitimate business what so ever! There is not a single legitimate address on those tarpits. Oh! The poor sucky spammer got stuck talking to a few thousand addresses on a machine that takes three minutes to tell him "OK". Sorry, no tears... They get exactly what they deserve. They got the addresses by violating the robots.txt rules and harvesting poisoned pages. That's the only way they will find those addresses. Tough. BTW... I'm seeing several spam address harvestors chewing on my sugarplums every week. It's getting close to seeing more spam address harvestors than seeing legitimate search engines through my web sites. Mind you... What I do is actually pretty minor. The potential for real damage really exists. Several anti-spam sites jokingly suggest that rejection codes should be "4xx" codes instead of "5xx" codes. Think about that for a second... They haven't transferred any data to you but you tell them to hold that data and try back later (4xx codes signify temporary errors that may be retried). So that data sits on their system until their final retries time out several days (5 days typical) later. Now... Take that and take advantage of the old "percent hack" that thousands of servers around the net still support (and are vulnerable open relays in and of their own right). Send a message to each of those servers pecent hacking a huge message at the chump you want to target with a final address of a system that blocks him with a 4xx code. With little effort you can totally shut down his mail spool and backup mail onto the percent hackable servers. Even if he manually cleans his spool, he's got another shit load or two waiting for him. Sites which permit open relaying are vulnerable to the 4xx code attacks. They have an open death trap DoS security vulnerability on them. The fact that we don't take advantage of it, means we're the nice guys. We only give them 5xx codes and tell them to go away... I have the right to decide, based on what ever criterion I chose, to accept or reject E-Mail. For the sites that I administer for a large E-Mail base, that needs to be in accordance with the established policies. In most cases, I have a hard time coming up with rules strict enough to adhere to those policies while still keeping the mail flowing. The owners of those sites have a right to dictate those policies. Not the senders. Matt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 10:30:14PM -0500, Gregory Maxwell wrote:
On Sun, Jan 07, 2001 at 08:22:28PM -0500, Michael H. Warfield wrote:
I already run several sugarplum sites with teergrubes. I also use
various blackhole lists and take other action against spammers, including
blocking entire rogue domains. If that rogue domain happens to be a two
letter TLD, so be it. If it gets bad enough, maybe they'll fix it.
You are suggesting that it is acceptable to implement technological
barriers to a minority expressing speech that is unacceptable to the
majority. This is not acceptable.
No... I'm say that their right to free speech does not trump
my right to not have to listen to it or download it and I determine
the criterion, they don't. I have, in my right to free speech, the
right to say screw off, I don't want to hear it.
When you subscript your mailbox to list of 'spammers' to avoid associating
with them, with the knowledge that you may lose some valuable mail, that is
fine.
Excuse me??? Clue alert! I'm not subscribing anything to any
spam mailbox. I'm not doing jack shit to subscribe myself to anything
to do with them. I am leaving bait around for them to screw themselves,
but I certainly have the free speech right to do that, now don't I?
I don't go to them and say "subscribe all these addresses". I don't
say to them, send E-Mail here. They are trespassing on my systems,
clearly stepping over well delineated boundries.
I'm really lost by your reasoning on this one. "Subscribing my
mailbox to a list of 'spammers' to avoid associating with them, with the
knowledge that you loose some valuable mail" makes absolutely no sense
what so ever. The legitimate mail I may or may not loose has no bearing
on the sugarplum or teergrube systems (which is what I'm assuming that
you are elluding to).
The situation is similar to not visiting a gay bar if you don't like
homosexual people. However, that is not what you are doing blocking whole
countries. That is like building concrete barriers around cites to punish
them for not oppressing their own minority citizen ("I'm going to block your
whole country until you outlaw this class of speech I find offensive").
Tough... I find the speech offensive, I don't have to listen
to it. If I find that the level of offensive speech from a particular
source exceeds all value, then I have the right to block it. They don't
like it, they have a right to change. Like I said... I don't take
active action against them. They have to come to me. They come to
my web site and step over my limits and contact my systems. I'm not
going to them.
Spam is not good, but destroying freedom is worse. I suggest that every
person who is eager to use oppressive technological measures to stop spammers
please consider the potential wider consequences.
Destroying my freedom is just as bad. I have the freedom to
choose and I have the freedom not to be plagued by the vermin who have
harvested my addresses and are using them in a way that violates my
acceptable use on my addresses.
Today the majority thinks spam is wrong, today you are a part of the
majority. The Internet should always avoid the tyranny of the masses, even
when it's operators are a part of the 'mass' today. Tomorrow the issue will
not be spam, and you might not be in the majority.
Not a problem. Won't be the first time and won't be the last time.
I deal and so shall they.
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Good mailing list.
On Tue, Jan 02, 2001 at 09:24:11AM -0500, Timothy A. DeWees wrote: > Hello, > Since it takes quite a it of time for me to deal with news groups, could > someone please point me to a _LINUX_ news group that could help me with > password sync between Unix and Windows. I am using Microsofts password sync > tool that comes with SFU 1.2. I know I sould ask Micr$loth, but I have been > for two mounths and thay refuse to help me. I get ignored in the Micro$loth > list, and I have a deadline. Besides, I have found that most linux hackers > know more about Micro$loth then the _GOOD_ people at Micro$sloth. You might be better off asking this up on one of the Samba mailing lists. We have options in Samba for simultaniously changing both the Windows NT password hashes and the Unix hashes where Samba is providing NT encrypted password authentication. You can also use pam_smb to use the NT password hashes for Unix password validation as well. In either case, it's more a generic Unix thing than it is a specific Linux thing and you're more like to find your answers in the Samba project. Try [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] > Thanks, and sorry for any disturbance! > -- > Kind Regards, > Timothy A. DeWees > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Good mailing list.
On Tue, Jan 02, 2001 at 09:24:11AM -0500, Timothy A. DeWees wrote: Hello, Since it takes quite a it of time for me to deal with news groups, could someone please point me to a _LINUX_ news group that could help me with password sync between Unix and Windows. I am using Microsofts password sync tool that comes with SFU 1.2. I know I sould ask Micr$loth, but I have been for two mounths and thay refuse to help me. I get ignored in the Micro$loth list, and I have a deadline. Besides, I have found that most linux hackers know more about Micro$loth then the _GOOD_ people at Micro$sloth. You might be better off asking this up on one of the Samba mailing lists. We have options in Samba for simultaniously changing both the Windows NT password hashes and the Unix hashes where Samba is providing NT encrypted password authentication. You can also use pam_smb to use the NT password hashes for Unix password validation as well. In either case, it's more a generic Unix thing than it is a specific Linux thing and you're more like to find your answers in the Samba project. Try [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Thanks, and sorry for any disturbance! -- Kind Regards, Timothy A. DeWees - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
