Re: util-linux: orphan
On Wed, 27 Dec 2006 23:12:51 +0100, Karel Zak said: > For example for my laptop is it true that "life is too short to > enable SELinux", but it's probably not true for servers in the bank where > I have money. (I hope so:-) On the other hand, the case can be made that your laptop needs SELinux *more* than the bank servers - because the bank servers are (presumably) heavily firewalled and stripped down software-wise, and otherwise hardened. But your laptop is exactly one Firefox buffer overflow from being completely pwned... pgpZ02vqGMqxp.pgp Description: PGP signature
Re: util-linux: orphan
On Wed, 27 Dec 2006, Theodore Tso wrote: > On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote: > > Frankly, it wasn't always easy to use SeLinux in previous FC > > releases, but there is huge progress and I think it's much better in > > FC6. > > I've never tried SELinux, but at one point there were all sorts of > horror stories that if you enabled SELinux, the moment you installed > any 3rd party software packages, whether it's Oracle or Websphere or > some other commercial application program, the application would break > because of all sorts of SELinux policy violations, and that it > required an SELinux wizard to configure SELinux policy to enable a 3rd > party application to actually work correctly. Given that I tried > enabling SELinux, witnessed things break spectacularly and with no > hints about how to fix things, I've always had the attitude of "life > is too short to enable SELinux", and so my limited experience is > consistent with all of the horror stories that I've heard. I see the fine grained security of Selinux as a big problem for third party applications. It's a big job to make the OS work cleanly with it but the fact is that many machines need to run significant 3rd party applications. I don't have first hand experience but I suspect most vendors have tight enough budgets without adding an Selinux developer and customers usually don't have this resource either so, by and large, I expect people will just have to disable it. I really don't see any solution to this problem either. Time will tell. Ian - 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: util-linux: orphan
Karel Zak wrote: For example for my laptop is it true that "life is too short to enable SELinux", but it's probably not true for servers in the bank where I have money. (I hope so:-) You'd be surprised how many banks run Windows, and not even the most recent versions. -hpa - 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: util-linux: orphan
On Wed, Dec 27, 2006 at 03:42:13PM -0500, Theodore Tso wrote: > On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote: > > Frankly, it wasn't always easy to use SeLinux in previous FC > > releases, but there is huge progress and I think it's much better in > > FC6. > > I've never tried SELinux, but at one point there were all sorts of > horror stories that if you enabled SELinux, the moment you installed > any 3rd party software packages, whether it's Oracle or Websphere or > some other commercial application program, the application would break > because of all sorts of SELinux policy violations, and that it > required an SELinux wizard to configure SELinux policy to enable a 3rd > party application to actually work correctly. Given that I tried > enabling SELinux, witnessed things break spectacularly and with no > hints about how to fix things, I've always had the attitude of "life > is too short to enable SELinux", and so my limited experience is The level of security is always your choice. The real security is pretty expensive and you have to invest your time to make your system really safe. IMHO people who provides simple and cheap solutions are liars or marketing-agents or both. For example for my laptop is it true that "life is too short to enable SELinux", but it's probably not true for servers in the bank where I have money. (I hope so:-) > consistent with all of the horror stories that I've heard. > > It sounds like SELinux has gotten better, according to your I'm really occasional selinux enduser only. So don't ask me for details. > description. Will handle arbitrary 3rd party software without running > wild, or is it still the case that the moment you want anything other > than software that was shipped with the distribution, it's "abandon > all hope, all ye who enter here"? There is possible customization of the existing selinux policy. You can generate a new loadable policy module from system audit logs (see audit2allow util). In the other words -- your system in the permissive mode is monitoring your 3rd party software and from the logs you can generate new selinux rules. And when you switch system to the enforcing mode the application should be run as expected with your new rules. Karel -- Karel Zak <[EMAIL PROTECTED]> - 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: util-linux: orphan
On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote: > Frankly, it wasn't always easy to use SeLinux in previous FC > releases, but there is huge progress and I think it's much better in > FC6. I've never tried SELinux, but at one point there were all sorts of horror stories that if you enabled SELinux, the moment you installed any 3rd party software packages, whether it's Oracle or Websphere or some other commercial application program, the application would break because of all sorts of SELinux policy violations, and that it required an SELinux wizard to configure SELinux policy to enable a 3rd party application to actually work correctly. Given that I tried enabling SELinux, witnessed things break spectacularly and with no hints about how to fix things, I've always had the attitude of "life is too short to enable SELinux", and so my limited experience is consistent with all of the horror stories that I've heard. It sounds like SELinux has gotten better, according to your description. Will handle arbitrary 3rd party software without running wild, or is it still the case that the moment you want anything other than software that was shipped with the distribution, it's "abandon all hope, all ye who enter here"? - Ted - 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: util-linux: orphan
On Wed, Dec 27, 2006 at 07:39:47PM +0100, Arnd Bergmann wrote:
> On Wednesday 27 December 2006 19:15, Karel Zak wrote:
> >
> > On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> > > On Monday 18 December 2006 08:17, Karel Zak wrote:
> > > > - remove FS/device detection code
> > > > (libblkid from e2fsprogs or libvolumeid is replacement)
> > >
> > > I saw that the current Fedora already dynamically links /bin/mount
> > > against /usr/lib/libblkid.so.
> >
> > Sorry, but it's nonsense.
> >
> > $ grep -r %{_root_libdir}/libblkid.so *
> >
> > devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
>
> Right, please accept my apologies for spreading confusion about this.
No problem ;-)
> I currently don't have access to the machine that broke, so I could
> not check the exact problem, and must have misremembered the bug.
>
> > > This obviously does not work if /usr is a separate partition that
> > > needs to be mounted with /bin/mount.
> >
> > Yes, I have /usr on a separate partition for many years :-)
> >
> > > I'd suggest that you make sure that mount always gets statically linked
> > > against libblkid to avoid these problems.
> >
> > It's dynamically linked in many distributions without a problem.
>
> The problem that I saw was because of selinux going wild. Statically linking
Yes, I remember the bug (or bugs). Fixed now.
> would have avoided the problem for me, but I guess this is just one
> more reason for me to disable selinux and be done with it.
Frankly, it wasn't always easy to use SeLinux in previous FC
releases, but there is huge progress and I think it's much better in
FC6.
Karel
--
Karel Zak <[EMAIL PROTECTED]>
-
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: util-linux: orphan
On Wednesday 27 December 2006 19:15, Karel Zak wrote:
>
> On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> > On Monday 18 December 2006 08:17, Karel Zak wrote:
> > > - remove FS/device detection code
> > > (libblkid from e2fsprogs or libvolumeid is replacement)
> >
> > I saw that the current Fedora already dynamically links /bin/mount
> > against /usr/lib/libblkid.so.
>
> Sorry, but it's nonsense.
>
> $ grep -r %{_root_libdir}/libblkid.so *
>
> devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
Right, please accept my apologies for spreading confusion about this.
I currently don't have access to the machine that broke, so I could
not check the exact problem, and must have misremembered the bug.
> > This obviously does not work if /usr is a separate partition that
> > needs to be mounted with /bin/mount.
>
> Yes, I have /usr on a separate partition for many years :-)
>
> > I'd suggest that you make sure that mount always gets statically linked
> > against libblkid to avoid these problems.
>
> It's dynamically linked in many distributions without a problem.
The problem that I saw was because of selinux going wild. Statically linking
would have avoided the problem for me, but I guess this is just one
more reason for me to disable selinux and be done with it.
Arnd <><
-
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: util-linux: orphan
On Wed, Dec 27, 2006 at 03:46:10AM +0100, Arnd Bergmann wrote:
> On Monday 18 December 2006 08:17, Karel Zak wrote:
> > - remove FS/device detection code
> > (libblkid from e2fsprogs or libvolumeid is replacement)
>
> I saw that the current Fedora already dynamically links /bin/mount
> against /usr/lib/libblkid.so.
Sorry, but it's nonsense.
$ grep -r %{_root_libdir}/libblkid.so *
devel/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-1/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-2/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-3/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-4/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-5/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
FC-5/e2fsprogs.spec~:%{_root_libdir}/libblkid.so.*
FC-6/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
RHEL-4/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
RHEL-5/e2fsprogs.spec:%{_root_libdir}/libblkid.so.*
(where %{_root_libdir} = /lib)
> This obviously does not work if /usr is a separate partition that
> needs to be mounted with /bin/mount.
Yes, I have /usr on a separate partition for many years :-)
> I'd suggest that you make sure that mount always gets statically linked
> against libblkid to avoid these problems.
It's dynamically linked in many distributions without a problem.
Karel
--
Karel Zak <[EMAIL PROTECTED]>
-
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: util-linux: orphan
On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote: > That's a pretty silly statement. The real issue is that any library > needed by binaries in /bin or /sbin should live in /lib, not /usr/lib. Well, there's a real treat here - lots of shared libraries mean mount is rendered unusable when they are not available for some reason. And there could be lots of reasons for this. We've seen selinux mislabeling with a fedoro-ish box in the lab, there is the possibility of unintentional ABI breaks and so on and so on. Then again using shared libraries has big advtantags over duplicating all the code, so I wouldn't want to say I'm totally against it. As mount only needs the various libraries for it's non-core features what about dlopen()ing those libraries? That way a messed up system at least has the bare mount functionality available. - 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: util-linux: orphan
Fedora rawhide (i686): $ rpm -qf /bin/mount util-linux-2.13-0.48.fc7 $ ldd /bin/mount linux-gate.so.1 => (0x00f9b000) libblkid.so.1 => /lib/libblkid.so.1 (0x45dbc000) libuuid.so.1 => /lib/libuuid.so.1 (0x45db6000) libselinux.so.1 => /lib/libselinux.so.1 (0x43c5c000) libc.so.6 => /lib/libc.so.6 (0x430d9000) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x4329c000) libdl.so.2 => /lib/libdl.so.2 (0x43255000) libsepol.so.1 => /lib/libsepol.so.1 (0x43c8b000) /lib/ld-linux.so.2 (0x5e3f7000) Aurora Corona (SPARC64): $ rpm -qf /bin/mount util-linux-2.13-0.44.sparc.al3 $ ldd /bin/mount libblkid.so.1 => /lib/libblkid.so.1 (0xf7fbc000) libuuid.so.1 => /lib/libuuid.so.1 (0xf7fa8000) libselinux.so.1 => /lib/libselinux.so.1 (0xf7f8) libc.so.6 => /lib/libc.so.6 (0xf7e1) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xf7dfc000) libdl.so.2 => /lib/libdl.so.2 (0xf7de4000) libsepol.so.1 => /lib/libsepol.so.1 (0xf7d88000) /lib/ld-linux.so.2 (0x7000) CentOS 4.4 (x86_64): $ rpm -qf /bin/mount util-linux-2.12a-16.EL4.20 $ ldd /bin/mount libc.so.6 => /lib64/tls/libc.so.6 (0x0031d6c0) /lib64/ld-linux-x86-64.so.2 (0x00552000) All look fine to me. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: util-linux: orphan
On Dec 27 2006 12:24, Alessandro Suardi wrote: > On 12/27/06, Theodore Tso <[EMAIL PROTECTED]> wrote: >> On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote: I saw that the current Fedora already dynamically links /bin/mount against /usr/lib/libblkid.so. This obviously does not work if /usr is a separate partition that needs to be mounted /with bin/mount. I also had problems with selinux claiming I had no right to access libblkid, which meant that the root fs could not be remounted r/w. I'd suggest that you make sure that mount always gets statically linked against libblkid to avoid these problems. >>> >>> That's a pretty silly statement. The real issue is that any >>> library needed by binaries in /bin or /sbin should live in /lib, >>> not /usr/lib. >> >> From a Debian unstable system: >> >> think:~# ldd /bin/mount >> libblkid.so.1 => /lib/libblkid.so.1 (0xb7f23000) > > FC6-current for i386 has it right: > > [EMAIL PROTECTED] ~]# ldd /bin/mount > libblkid.so.1 => /lib/libblkid.so.1 (0x4b607000) And so does openSUSE 10.2: ichi$ ldd /bin/mount libblkid.so.1 => /lib/libblkid.so.1 (0xa7f4f000) Interestingly enough, SUSE Linux 10.1 i586/x86_64 had it statically ccg$ ldd /bin/mount libc.so.6 => /lib64/libc.so.6 (0x2b489072e000) /lib64/ld-linux-x86-64.so.2 (0x4000) (that's all folks) Now what puzzles is that FC6's mapping address is quite 'off' - the host "think" has it near PAGE_OFFSET (0xc000), as does "ichi" (PAGE_OFFSET=0xb000), so what's with "sandman"? -`J' -- - 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: util-linux: orphan
On 12/27/06, Theodore Tso <[EMAIL PROTECTED]> wrote: On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote: > >I saw that the current Fedora already dynamically links /bin/mount > >against /usr/lib/libblkid.so. This obviously does not work if > >/usr is a separate partition that needs to be mounted with /bin/mount. > >I also had problems with selinux claiming I had no right to access > >libblkid, which meant that the root fs could not be remounted r/w. > > > >I'd suggest that you make sure that mount always gets statically linked > >against libblkid to avoid these problems. > > That's a pretty silly statement. The real issue is that any library > needed by binaries in /bin or /sbin should live in /lib, not /usr/lib. From a Debian unstable system: think:~# ldd /bin/mount linux-gate.so.1 => (0xe000) libblkid.so.1 => /lib/libblkid.so.1 (0xb7f23000) libuuid.so.1 => /lib/libuuid.so.1 (0xb7f2) libc.so.6 => /lib/libc.so.6 (0xb7ddf000) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xb7dcd000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7db8000) libsepol.so.1 => /lib/libsepol.so.1 (0xb7d77000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7d61000) /lib/ld-linux.so.2 (0xb7f3f000) libdl.so.2 => /lib/libdl.so.2 (0xb7d5d000) ... and in fact the e2fsprogs's configure program normally installs the critical libraries used by mount, fsck, e2fsck, including the blkid and uuid libraries, in /lib, not /usr/lib. If blkid is being installed in /usr/lib in Fedora, someone must have gone out of their way to override e2fsprogs' defaults, which are designed to do the right things by default. (Basically, because I generally don't trust the choices made by distributions' packaging engineers, having been burned more than once. :-) - Ted FC6-current for i386 has it right: [EMAIL PROTECTED] ~]# rpm -qf /bin/mount util-linux-2.13-0.45.3.fc6 [EMAIL PROTECTED] ~]# ldd /bin/mount linux-gate.so.1 => (0xb7f63000) libblkid.so.1 => /lib/libblkid.so.1 (0x4b607000) libuuid.so.1 => /lib/libuuid.so.1 (0x4b601000) libselinux.so.1 => /lib/libselinux.so.1 (0x49ce5000) libc.so.6 => /lib/libc.so.6 (0x00aec000) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x49cfe000) libdl.so.2 => /lib/libdl.so.2 (0x00c54000) libsepol.so.1 => /lib/libsepol.so.1 (0x4a603000) /lib/ld-linux.so.2 (0x0011d000) --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - 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: util-linux: orphan
On Tue, Dec 26, 2006 at 07:08:43PM -0800, H. Peter Anvin wrote: > >I saw that the current Fedora already dynamically links /bin/mount > >against /usr/lib/libblkid.so. This obviously does not work if > >/usr is a separate partition that needs to be mounted with /bin/mount. > >I also had problems with selinux claiming I had no right to access > >libblkid, which meant that the root fs could not be remounted r/w. > > > >I'd suggest that you make sure that mount always gets statically linked > >against libblkid to avoid these problems. > > That's a pretty silly statement. The real issue is that any library > needed by binaries in /bin or /sbin should live in /lib, not /usr/lib. >From a Debian unstable system: think:~# ldd /bin/mount linux-gate.so.1 => (0xe000) libblkid.so.1 => /lib/libblkid.so.1 (0xb7f23000) libuuid.so.1 => /lib/libuuid.so.1 (0xb7f2) libc.so.6 => /lib/libc.so.6 (0xb7ddf000) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xb7dcd000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7db8000) libsepol.so.1 => /lib/libsepol.so.1 (0xb7d77000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7d61000) /lib/ld-linux.so.2 (0xb7f3f000) libdl.so.2 => /lib/libdl.so.2 (0xb7d5d000) ... and in fact the e2fsprogs's configure program normally installs the critical libraries used by mount, fsck, e2fsck, including the blkid and uuid libraries, in /lib, not /usr/lib. If blkid is being installed in /usr/lib in Fedora, someone must have gone out of their way to override e2fsprogs' defaults, which are designed to do the right things by default. (Basically, because I generally don't trust the choices made by distributions' packaging engineers, having been burned more than once. :-) - Ted - 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: util-linux: orphan
Once upon a time, Arnd Bergmann <[EMAIL PROTECTED]> said: >I saw that the current Fedora already dynamically links /bin/mount >against /usr/lib/libblkid.so. What do you mean by "current" Fedora? I think the first Fedora version that linked /bin/mount against libblkid.so was FC4, and FC4, FC5, FC6, and rawhide all have libblkid.so in /lib. -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. - 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: util-linux: orphan
On Wednesday 27 December 2006 04:08, H. Peter Anvin wrote: > > > I'd suggest that you make sure that mount always gets statically linked > > against libblkid to avoid these problems. > > > > That's a pretty silly statement. The real issue is that any library > needed by binaries in /bin or /sbin should live in /lib, not /usr/lib. Right, this is obviously true in general. I don't understand enough about selinux (who does?) to be sure what went wrong there on top of this, but my impression was that I could have solved the problem if I had been able to remount the root partition, or mount the selinux file system, which was made impossible by the fact that I had no permission to access one of the libraries for the mount binary. The location of the library file was not the problem I had, as that system doesn't have a separate /usr partition. Arnd <>< - 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: util-linux: orphan
Arnd Bergmann wrote: On Monday 18 December 2006 08:17, Karel Zak wrote: - remove FS/device detection code (libblkid from e2fsprogs or libvolumeid is replacement) I saw that the current Fedora already dynamically links /bin/mount against /usr/lib/libblkid.so. This obviously does not work if /usr is a separate partition that needs to be mounted with /bin/mount. I also had problems with selinux claiming I had no right to access libblkid, which meant that the root fs could not be remounted r/w. I'd suggest that you make sure that mount always gets statically linked against libblkid to avoid these problems. That's a pretty silly statement. The real issue is that any library needed by binaries in /bin or /sbin should live in /lib, not /usr/lib. -hpa - 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: util-linux: orphan
On Monday 18 December 2006 08:17, Karel Zak wrote: > - remove FS/device detection code > (libblkid from e2fsprogs or libvolumeid is replacement) I saw that the current Fedora already dynamically links /bin/mount against /usr/lib/libblkid.so. This obviously does not work if /usr is a separate partition that needs to be mounted with /bin/mount. I also had problems with selinux claiming I had no right to access libblkid, which meant that the root fs could not be remounted r/w. I'd suggest that you make sure that mount always gets statically linked against libblkid to avoid these problems. Arnd <>< - 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: util-linux: orphan
>> What about merging util-linux and procps?
>
> How? Which way?
In that all the following tools (and possibly files) which are
returned by `rpm ql procps` replace the util-linux counterparts, if
any. Note that rpm -ql might return less programs than actually
present in procps, since distributors need to choose which program to
pick from what {util-linux or procps}.
21:07 ichi:~ > rpm -ql procps
/bin/ps
/etc/init.d/boot.sysctl
/etc/sysctl.conf
/etc/xinetd.d/systat
/sbin/sysctl
/usr/bin/free
/usr/bin/pgrep
/usr/bin/pkill
/usr/bin/pmap
/usr/bin/pwdx
/usr/bin/skill
/usr/bin/slabtop
/usr/bin/snice
/usr/bin/tload
/usr/bin/top
/usr/bin/vmstat
/usr/bin/w
/usr/bin/watch
+ the stuff in /usr/share/doc and /usr/share/man
with the idea that you retain maintership over these. So my proposal/idea was
just one of how to package it.
> being bogged down in problems. One by one, the various
> Linux distributions switched over to my version of the code.
>
> So as you may imagine, I'd be rather nervous about letting
> procps get into that situation again. Bugs are yucky. Having
> multiple committers and no testing is a sure path to ruin.
-`J'
--
-
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: util-linux: orphan
On 12/20/06, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> I've originally thought about util-linux upstream fork,
>> but as usually an fork is bad step. So.. I'd like to start
>> some discussion before this step.
> ...
>> after few weeks I'm pleased to announce a new "util-linux-ng"
>> project. This project is a fork of the original util-linux (2.13-pre7).
>
> Well, how about giving me a chunk of it? I'd like /bin/kill please.
> I already ship a nicer one in procps anyway, so you can just delete
> the files and call that done. (just today I was working on a Fedora
> system and /bin/kill annoyed me)
How can you ship a "nicer" kill, given that its sole purpose is to accept
kill { -l | -t | {-s SIGNUM | -SIGNAME } somepid [morepids] }
?
I checked compatibility with Solaris, Tru64, probably a few BSDs,
and man pages of many others.
Fedora Core 5 doesn't seem to like this command:
/bin/kill -l 17 19
(which reminds me, I need to add sigqueue support and
maybe tgkill support)
What about merging util-linux and procps?
How? Which way?
As I mentioned before, I was twice disappointed in missing
announcements of util-linux maintainership being up for grabs.
I certainly have a track record for keeping things stable.
Prior to me, procps has a history of being abandoned and
broken. Procps is a fork of the long-dead kmem-ps project.
Procps was then passed to someone who added color and
then disappeared. The prior maintainer picked up the old
code again, no doubt under influence of his employer Red Hat.
I rewrote much of it then, but had trouble getting in all of
my changes. Debian started using my code, which slowly
turned into a fork. Maintainership was passed to somebody
else, without even telling me. That person and his immediate
successor added numerous serious bugs. Inexperience with
the code and the lack of a test suite soon led to that group
being bogged down in problems. One by one, the various
Linux distributions switched over to my version of the code.
So as you may imagine, I'd be rather nervous about letting
procps get into that situation again. Bugs are yucky. Having
multiple committers and no testing is a sure path to ruin.
-
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: util-linux: orphan
>> I've originally thought about util-linux upstream fork,
>> but as usually an fork is bad step. So.. I'd like to start
>> some discussion before this step.
> ...
>> after few weeks I'm pleased to announce a new "util-linux-ng"
>> project. This project is a fork of the original util-linux (2.13-pre7).
>
> Well, how about giving me a chunk of it? I'd like /bin/kill please.
> I already ship a nicer one in procps anyway, so you can just delete
> the files and call that done. (just today I was working on a Fedora
> system and /bin/kill annoyed me)
How can you ship a "nicer" kill, given that its sole purpose is to accept
kill { -l | -t | {-s SIGNUM | -SIGNAME } somepid [morepids] }
?
What about merging util-linux and procps?
-`J'
--
-
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: util-linux: orphan
Karel Zak writes: I've originally thought about util-linux upstream fork, but as usually an fork is bad step. So.. I'd like to start some discussion before this step. ... after few weeks I'm pleased to announce a new "util-linux-ng" project. This project is a fork of the original util-linux (2.13-pre7). Aw damn, I missed it again. LKML gets about 300 posts/day. The last time util-linux was offered, I missed out. Bummer. Well, how about giving me a chunk of it? I'd like /bin/kill please. I already ship a nicer one in procps anyway, so you can just delete the files and call that done. (just today I was working on a Fedora system and /bin/kill annoyed me) VERY STRONG SUGGESTION: build a full test suite before you mess with the source. This isn't some cute toy like xeyes or a silly game. This is util-linux, which MUST work. - 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: util-linux: orphan
On Mon, Dec 18, 2006 at 10:33:33AM +0100, Jan Engelhardt wrote: > > > after few weeks I'm pleased to announce a new "util-linux-ng" project. This > > project is a fork of the original util-linux (2.13-pre7). > > > > The goal of the project is to move util-linux code back to useful state, > > sync > > with actual distributions and kernel and make development more transparent > > end > > open. > > If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be > the maintainer, ask if you can take over, including the name. On Mon, Dec 18, 2006 at 10:55:05AM +0100, Arkadiusz Miskiewicz wrote: > On Monday 18 December 2006 08:52, Karel Zak wrote: > > I'm pleased to announce a new "util-linux-ng" project. This project > > is a fork of the original util-linux (2.13-pre7). > > Fork? Are you saying that you just didn't take over maintainership and now we > will have two versions of util-linux!? :/ People around util-linux-ng are not so naive ;-) We spent last month with discussion about a way how (non-)fork this project. We made decision that a fork is the right way, because Adrian Bunk completely ignores __everyone__ who wants to talk with him about utils-linux. A fork is nothing attractive, but it's also a way how improve things in Open Source world. The goal is not only improve source code, but also a way how this project is maintained (mailing list, discussion about changes, git, transparent development, ...). Karel -- Karel Zak <[EMAIL PROTECTED]> - 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: util-linux: orphan
Jan Engelhardt <[EMAIL PROTECTED]> writes: >> after few weeks I'm pleased to announce a new "util-linux-ng" project. This >> project is a fork of the original util-linux (2.13-pre7). >> >> The goal of the project is to move util-linux code back to useful state, sync >> with actual distributions and kernel and make development more transparent >> end >> open. > > If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be > the maintainer, ask if you can take over, including the name. Well, there hasn't been any response since about one month. I think the decision to fork in this situation is reasonable. We all hope that it will be just a temporary fork. Matthias - 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: util-linux: orphan
On Monday 18 December 2006 10:33, Jan Engelhardt wrote: > > after few weeks I'm pleased to announce a new "util-linux-ng" project. > > This project is a fork of the original util-linux (2.13-pre7). > > > > The goal of the project is to move util-linux code back to useful state, > > sync with actual distributions and kernel and make development more > > transparent end open. > > If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be > the maintainer, ask if you can take over, including the name. > This smells a lot like the RPM case [ http://lwn.net/Articles/196523/ ] > however, it does not look like anyone is going to call it rpm-ng just > because the original name is owned by the last maintainer. rpm.org case is even worse. Original maintainer still develops rpm - at this moment version 4.4.7 at http://wraptastic.org/ (while rpm.org starts from older 4.4.2 codebase), there is active mailing list, so we have two running projects with the same name which is bad thing and will cause confusion. I hope that there will be one util-linux and one rpm project. > Regards, > -`J' -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ - 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: util-linux: orphan
> after few weeks I'm pleased to announce a new "util-linux-ng" project. This > project is a fork of the original util-linux (2.13-pre7). > > The goal of the project is to move util-linux code back to useful state, sync > with actual distributions and kernel and make development more transparent end > open. If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be the maintainer, ask if you can take over, including the name. This smells a lot like the RPM case [ http://lwn.net/Articles/196523/ ] however, it does not look like anyone is going to call it rpm-ng just because the original name is owned by the last maintainer. Regards, -`J' -- - 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: util-linux: orphan
Hello, after few weeks I'm pleased to announce a new "util-linux-ng" project. This project is a fork of the original util-linux (2.13-pre7). The goal of the project is to move util-linux code back to useful state, sync with actual distributions and kernel and make development more transparent end open. The short term goals (for 2.13 release): - remove all NFS code from util-linux-ng (/sbin/mount.nfs from nfs-utils is replacement) - remove FS/device detection code (libblkid from e2fsprogs or libvolumeid is replacement) - move as much as possible patches from distributions to upstream Mailing list: http://vger.kernel.org/vger-lists.html#util-linux-ng FTP: ftp://ftp.kernel.org/pub/scm/utils/util-linux-ng/ GIT: git clone git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git util-linux-ng [Note, GIT repo contains previous 47 versions of util-linux.] The mailing list or my private e-mail are open for your patches, ideas and suggestion. The mailing list is also place where you can help us review patches. Thanks mostly to Ian Kent, P.H. Anvin. Well, and thanks to Adrian Bunk for his previous work on this package. Karel On Thu, Nov 09, 2006 at 11:41:57PM +0100, Karel Zak wrote: > > It really seems that util-linux project is in a bad condition: > > * the latest *major* stable release: 05-Mar-2004 (util-linux-2.12a) > * the latest *minor* stable release: 23-Sep-2005 (util-linux-2.12r) > * the latest unstable release: 05-Mar-2006 (util-linux-2.13-pre7) > * missing source code repository > * missing web page > * maintainer (Adrian Bunk) completely ignores mails about this package > * source code doesn't follow linux kernel, because there isn't any > development > * contributors are sending their patches to distributions rather than > to upstream > * Red Hat (FC6) has 75 patches for this package (!) > * Novell has (OpenSuse 10.2) 53 patches for this package (!) > > > I'm Red Hat util-linux maintainer (for 2 years) and I'd like to > change this bad situation. Yes.. I'd like to help. I've already > talked with Peter Anvin about git repository for this project at > kernel.org. Also I have feedback from Novell that they agree that the > current situation is bad and they want to contribute future > development. > > I've originally thought about util-linux upstream fork, but as > usually an fork is bad step. So.. I'd like to start some discussion > before this step. Maybe Adrian will be realistic and he will leave > the project and invest all his time to kernel only. -- Karel Zak <[EMAIL PROTECTED]> - 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/
