Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package
Chris Lawrence
Version: N/A; reported 2002-02-18
Severity: wishlist
* Package name : lsb
Version : 1.1.0
* URL : http://www.linuxbase.org/
* License : GPL, BSD
Description : Linux Standard Base 1.1 core support package
The Linux Standard Base (http://www.linuxbase.org/) is a standard
core system that third-party applications can depend upon.
.
This package provides an implementation of version 1.1.0 of the Linux
Standard Base for Debian on the Intel x86 architecture. Future
revisions may support the LSB on additional architectures.
.
The intent of this package is to provide a best current practice way
of installing LSB packages on Debian GNU/Linux. Its presence does
not imply that we believe that Debian fully complies with the Linux
Standard Base, and should not be construed as a statement that Debian
is LSB-compliant.
My README.Debian text follows, which pretty much explains how this
package works:
lsb for Debian
--------------
This package attempts to implement the core LSB specification. Much
of the implementation is drawn on a talk by Wichert Akkerman
(http://www.liacs.nl/~wichert/talks/LSBDistro/html/) and Matt
Taggert's discussion of LSB 1.0 and Debian
(http://people.debian.org/~taggart/lsb/).
It does so in a number of ways:
- Providing directories that appear to be missing from Debian's FHS
hierarchy. (These directories probably should appear in base-files
eventually.)
- Depending upon packages that implement OS services required by the
LSB, including libraries and programs.
- Including the ld-lsb.so.1 symlink to the dynamic linker.
- Providing the LSB init script functionality. Some of the LSB init
functionality cannot be implemented without cooperation from other
packages or changes in policy for woody+1; however, the remainder is
provided here.
The intent of this package is to provide a best current practice way
of installing LSB packages on Debian woody on the ia32 architecture.
Its presence does not imply that I believe that Debian fully complies
with the Linux Standard Base, and should not be construed as a
statement that Debian is LSB-compliant.
DEVIATIONS FROM LSB 1.1
The package and its dependencies implement all of LSB on Debian, with
these exceptions:
- LSB 1.1 assumes a 2.4 kernel. Debian ships a 2.2 kernel by default
as of woody, although 2.4 is optional. There is no way in the
Debian system to ensure a package is only installed on a specific
kernel release.
- LSB 1.1 specifies definitions for run levels 2-5 that correspond
with most Red Hat-like distributions. Debian does not specify run
levels 3-5, and RL 2 can theoretically encompass any of LSB 2-5.
(LSB probably should implement init dependencies for facilities
expected in run levels, rather than using run levels directly.)
In practical terms, this means that some packages may not install
init scripts in RL 2-4 that would be expected on a system running an
X display manager. This package obeys the LSB spec by using the
specified run levels of LSB applications; however, my gut feeling is
that any LSB RL from 2-5 should be treated as 2-5 inclusive on
Debian until Debian conforms (unlikely for woody) or LSB is amended
to get rid of this silliness.
- LSB 1.1 doesn't fully specify what the init_functions should do. I
have chosen to implement them in a way that is consistent with
Debian current practice, using the start-stop-daemon utility and the
echo command. For woody+1, I expect a nicer init logging facility
that could be used.
LSB specifies no way for a binary to request that a pid file be
created for it, and the spec is ambiguous about whether start_daemon
should create the pid file, therefore I assume the binary will
produce its own /var/run/basename.pid file.
There may be other deviations from the spec; they are bugs and should
be reported as such. (The aforementioned deviations are bugs, but
probably "wontfix" for woody, or are bugs in the spec.)
DESIGN DECISIONS
- I implemented the LSB init dependencies based on sysvinit's priority
support. A registry of package-provided facilities and their
start and stop priorities is retained in /var/lib/lsb/facilities.
Priorities are assigned to the system facilities as found on my
unstable boxen as of today; perhaps system facilities should be
registered by the appropriate packages, and not managed by the lsb
package, but that is a woody+1 policy decision.
- The facility handling scripts are written in Python. I am not
particularly attached to them being written in Python, but at the
same time I do not forsee rewriting them in $language_of_choice.
NOTES
Per the spec, LSB applications may be installed on Debian using:
alien -i YOUR_APPLICATION_HERE.lsb
You may need to run 'apt-get -f install' afterwards to pull in this
package. Of course, you wouldn't be reading this if you hadn't
already pulled it in.
-- Chris Lawrence <lawr...@debian.org>, Sun, 17 Feb 2002 14:07:32 -0600
The package in source and i386 binary (it's really arch-independent,
but the spec only is final on Linux/ia32) is at
http://people.debian.org/~lawrencc/
Note: I can't actually find any LSB packages that test whether the
implementation works right or not. I downloaded the lsb-apache rpm
from ftp://freestandards.org/pub/lsb/app-battery/apache/, and alien
handled it OK, and dpkg installed it without complaining of missing
dependencies, but an equivs-based lsb could have done that! (The
prerm and postinst don't do anything...)
(Alien chokes on their rsync:
Unpacking of `rsync-2.4.6-1.i386.rpm' failed at /usr/share/perl5/Alien/Package/Rpm.pm line 140.
Mozilla doesn't have an LSB rpm.)
Your questions and comments are most welcome. I'd particularly like
any comments on streamlining and generalizing the depends list, as I
suspect a few redundant dependencies are in there (alien probably
pulls in a lot of libraries based on what it pulls in, for example).
Also, if you actually have a LSB package that uses the init
facilities, I'd love to see test results.
Finally, the package probably should be built as native but numbered
(like now) as UPSTREAM-DEB.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux quango4 2.4.18-pre7-ac1 #1 Tue Jan 29 15:12:07 CST 2002 i686
Locale: LANG=C, LC_CTYPE=en_US
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christopher Yeoh
>
> There may be other deviations from the spec; they are bugs and should
> be reported as such. (The aforementioned deviations are bugs, but
> probably "wontfix" for woody, or are bugs in the spec.)
If you do find bugs please report them as development of the
specification is ongoing.
> Per the spec, LSB applications may be installed on Debian using:
>
> alien -i YOUR_APPLICATION_HERE.lsb
I'm pretty sure that the use of .lsb as the suffix for LSB compliant
packages did not make it into the 1.1 specification.
> Note: I can't actually find any LSB packages that test whether the
> implementation works right or not. I downloaded the lsb-apache rpm
For the testing of distributions there is also a set of test suites
available. The test suites will be used as part of the compliance
testing of distributions.
ftp://ftp.freestandards.org/pub/lsb/test_suites/beta/binary/distribution
Note: The packages is the beta directory are currently a bit better
than those in the released directory.
> (Alien chokes on their rsync:
> Unpacking of `rsync-2.4.6-1.i386.rpm' failed at /usr/share/perl5/Alien/Package/Rpm.pm line 140.
IIRC that used to work with earlier versions of alien. Its a very
simple package.
Chris
--
cy...@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia
Chris Lawrence
> At 2002/2/18 18:50-0600 Chris Lawrence writes:
> >
> > There may be other deviations from the spec; they are bugs and should
> > be reported as such. (The aforementioned deviations are bugs, but
> > probably "wontfix" for woody, or are bugs in the spec.)
>
> If you do find bugs please report them as development of the
> specification is ongoing.
Will do. The uid/gid 1 issue is definitely an issue; Debian probably
can't make that change, and I suspect many other LSB implementations
would trip over it too if they have any POSIX already.
> > Per the spec, LSB applications may be installed on Debian using:
> >
> > alien -i YOUR_APPLICATION_HERE.lsb
>
> I'm pretty sure that the use of .lsb as the suffix for LSB compliant
> packages did not make it into the 1.1 specification.
Right; I'll fix that.
> > Note: I can't actually find any LSB packages that test whether the
> > implementation works right or not. I downloaded the lsb-apache rpm
>
> For the testing of distributions there is also a set of test suites
> available. The test suites will be used as part of the compliance
> testing of distributions.
>
> ftp://ftp.freestandards.org/pub/lsb/test_suites/beta/binary/distribution
>
> Note: The packages is the beta directory are currently a bit better
> than those in the released directory.
I'll take a look at this one.
> > (Alien chokes on their rsync:
> > Unpacking of `rsync-2.4.6-1.i386.rpm' failed at /usr/share/perl5/Alien/Package/Rpm.pm line 140.
>
> IIRC that used to work with earlier versions of alien. Its a very
> simple package.
joeyh says the archive might be truncated... as it is, it's 1/3 the
size of the source, which may be off a tad. (See #134656)
Chris
--
Chris Lawrence <lawr...@debian.org> - http://www.lordsutch.com/chris/
Wichert Akkerman
> Will do. The uid/gid 1 issue is definitely an issue; Debian probably
> can't make that change, and I suspect many other LSB implementations
> would trip over it too if they have any POSIX already.
We can just drop most of the standard accounts and become compatible
by simply not having an optional account. Most of bin/daemon/sync/etc.
aren't used anyway it seems.
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Chris Lawrence
> Previously Chris Lawrence wrote:
> > Will do. The uid/gid 1 issue is definitely an issue; Debian probably
> > can't make that change, and I suspect many other LSB implementations
> > would trip over it too if they have any POSIX already.
>
> We can just drop most of the standard accounts and become compatible
> by simply not having an optional account. Most of bin/daemon/sync/etc.
> aren't used anyway it seems.
Unfortunately, the following accounts are required (per
http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/usernames.html):
USER GROUP UID GID
root root 0 0
bin bin 1 1
daemon daemon X X
X = unspecified
On Debian:
USER GROUP UID GID
root root 0 0
bin bin 2 2
daemon daemon 1 1
So, either we need to figure out how to get bin and daemon to swap (or
at least move daemon somewhere else and move bin from 2 to 1), or the
spec needs to change.
Frankly, I can't see any reason why uid/gid 1 should be assumed to be
bin, especially since no other UIDs and GIDs are static (except 0,
which is embedded in the kernel design...). After all, that's why we
have getpwuid()...
Chris
--
Chris Lawrence <lawr...@debian.org> - http://www.lordsutch.com/chris/
Andrew Pimlott
> Unfortunately, the following accounts are required (per
> http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/usernames.html):
>
> USER GROUP UID GID
> root root 0 0
> bin bin 1 1
> daemon daemon X X
>
> X = unspecified
>
> On Debian:
>
> USER GROUP UID GID
> root root 0 0
> bin bin 2 2
> daemon daemon 1 1
>
> So, either we need to figure out how to get bin and daemon to swap (or
> at least move daemon somewhere else and move bin from 2 to 1), or the
> spec needs to change.
I would lobby to change the spec not to mention bin, daemon, or any
of the optional users/groups, at all. They are not specified in a
useful way, so they're at best dead-weight, and at worst an
opportunity for conflicting interpretations.
I filed a bug to this effect with a subject like "user specification
is worse than useless". (The sourceforge page is down, so I can't
find a URL now.)
Andrew
Martijn van Oosterhout
> On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote:
> I would lobby to change the spec not to mention bin, daemon, or any
> of the optional users/groups, at all. They are not specified in a
> useful way, so they're at best dead-weight, and at worst an
> opportunity for conflicting interpretations.
IIRC, I think the reasoning went as follows:
- The LSB format is based on RPM which has a CPIO archive
- CPIO archives store uid/gids as numbers, not names
- Installed programs may want to use the daemon user
- Hence the daemon user must have a fixed uid
Tar stores names instead of numbers and so doesn't suffer from this problem.
Note that once the program is running, it can use getpwent(). We're talking
about silliness in cpio itself. I beleive the cpio new archive format fixes
but it's not well supported.
> I filed a bug to this effect with a subject like "user specification
> is worse than useless". (The sourceforge page is down, so I can't
> find a URL now.)
Kind of funny that we would have to start changing the mappings of uids
just because some people decided to use RPM as a standard install format.
Ofcourse, I could be making this up...
--
Martijn van Oosterhout <kle...@svana.org>
http://svana.org/kleptog/
> Terrorists can only take my life. Only my government can take my freedom.
Thorsten Kukuk
> On Tue, Feb 19, 2002 at 12:09:51AM -0500, Andrew Pimlott wrote:
> > On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote:
> > I would lobby to change the spec not to mention bin, daemon, or any
> > of the optional users/groups, at all. They are not specified in a
> > useful way, so they're at best dead-weight, and at worst an
> > opportunity for conflicting interpretations.
>
> IIRC, I think the reasoning went as follows:
> - The LSB format is based on RPM which has a CPIO archive
> - CPIO archives store uid/gids as numbers, not names
> - Installed programs may want to use the daemon user
> - Hence the daemon user must have a fixed uid
Have you ever looked at RPM? I don't know which cpio format the RPM
internal cpio is using, but the above is wrong, the demon user must
not have a fixed uid. RPM does not depend on fixed uids.
> Kind of funny that we would have to start changing the mappings of uids
> just because some people decided to use RPM as a standard install format.
Which is also wrong. This has nothing to do with the fact that LSB
has decide to use the RPMv3 package format for delivering programs.
Thorsten
--
Thorsten Kukuk http://www.suse.de/~kukuk/ ku...@suse.de
SuSE Linux AG Deutschherrenstr. 15-19 D-90429 Nuernberg
--------------------------------------------------------------------
Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
Chris Lawrence
> On Tue, Feb 19, Martijn van Oosterhout wrote:
>
> > On Tue, Feb 19, 2002 at 12:09:51AM -0500, Andrew Pimlott wrote:
> > > On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote:
> > > I would lobby to change the spec not to mention bin, daemon, or any
> > > of the optional users/groups, at all. They are not specified in a
> > > useful way, so they're at best dead-weight, and at worst an
> > > opportunity for conflicting interpretations.
> >
> > IIRC, I think the reasoning went as follows:
> > - The LSB format is based on RPM which has a CPIO archive
> > - CPIO archives store uid/gids as numbers, not names
> > - Installed programs may want to use the daemon user
> > - Hence the daemon user must have a fixed uid
>
> Have you ever looked at RPM? I don't know which cpio format the RPM
> internal cpio is using, but the above is wrong, the demon user must
> not have a fixed uid. RPM does not depend on fixed uids.
Heh... this discussion was on lsb-discuss, what, 6 months ago.
As far as I can figure out, there is no technical reason to require
uid and gid 1 to be bin, and it's bad programming practice to assume
any uid corresponds to any named user. When this last came up, I
don't think anyone came up with a good reason not to drop the
specification; indeed, I assumed it was gone until I went back and
reread the section closely.
Let's put it this way: making uid/gid 1 a requirement means Debian
probably will never conform to the spec, because of the problem of
breaking existing installs. It also creates problems for people who
want to use NIS across multiple systems, as Solaris uses uid/gid 2 for
bin (like Debian), or running LSB apps on Solaris/x86, which could be
conformant if Sun or a third party wanted to do the work.
Chris
--
Chris Lawrence <lawr...@debian.org> - http://www.lordsutch.com/chris/
Chad C. Walstrom
> Let's put it this way: making uid/gid 1 a requirement means Debian
> probably will never conform to the spec, because of the problem of
> breaking existing installs.
Only apply the changes to new installs. Alternatively, create a
configlet script for the Sysadmin to use while in single-user mode to
change over things. We're not changing root here, just bin and daemon.
I don't know any application that runs as daemon that still runs in
single user mode.
#!/bin/sh
#
# swap uid/gid btwn bin & daemon users/groups
#
# DISCLAIMER -- this is a hack intended for sysadmins willing to get
# their hands dirty once and a while.
#
>/etc/nologin
groupmod -gid 1 -o bin
groupmod -gid 2 -o daemon
usermod -uid 1 -gbin bin
usermod -uid 2 -gdaemon daemon
find / -uid 1 -gid 1 -exec chown 2:1 \{\} \; -print > /tmp/2:1.list
find / -uid 2 -gid 2 -exec chown 1:1 \{\} \;
# already found the files...chown them again to their final uid:gid
cat /tmp/2:1.list | xargs chown 2:2
rm /tmp/2:1.list
rm /etc/nologin
If we have to, we could create/choose a high, random uid that isn't
being used as the swap point.
> It also creates problems for people who want to use NIS across
> multiple systems, as Solaris uses uid/gid 2 for bin (like Debian), or
> running LSB apps on Solaris/x86, which could be conformant if Sun or a
> third party wanted to do the work.
IMHO, you should not be sharing low uid/gid's over NIS, PERIOD, end of
sentance. Your NIS uid/gid should be somewhere abovbe 1500 so that your
system and operator accounts don't require full-time network connections
to be accessible. How many times has your NFS server died or
experienced lag, locking you out of your home directory? How many times
have you been unable to login because some system profile script
requires a file on an NFS automounted directory. How about NIS dying
and no-one being able to login except root?
It happens. All the time. Why? Badly configured systems, often
inherited from one BOFH to another (It's not my fault! -- Han Solo).
The fix? Manual labor, headaches, and lots of coffee. I know this from
recent experience (geeze, every day, in fact).
Should LSB be pushing us around over small, usually systems management
related tasks? Probably not. Should the LSB be a good guideline on
setting up a sane system to begin with? Certainly. Should we conform
to LSB whenever possible. Absolutely. Does this mean we need to
convert every running system over to accomedate a uid/gid change? No.
The robust solution to such a switch would have to incorporate more
tools than I listed above, such as 'ps' and 'fopen'. Perl or Python may
be a nice, one-tool approach, and it sounds like the base Debian system
should have at least Perl for the time being.
Anyway, it's late, and I'm tired. Night!
--
Chad Walstrom <che...@wookimus.net> | a.k.a. ^chewie
http://www.wookimus.net/ | s.k.a. gunnarr
Get my public key, ICQ#, etc. $(mailx -s 'get info' che...@wookimus.net)
Alan Cox
> - The LSB format is based on RPM which has a CPIO archive
> - CPIO archives store uid/gids as numbers, not names
RPM does not have that limitation
> - Hence the daemon user must have a fixed uid
RPM does not have that limitation either
> Note that once the program is running, it can use getpwent(). We're talking
Doesn't help you - the password file is not the first package installed on
a typical distro
> Ofcourse, I could be making this up...
Probably
Alan Cox
> bin, especially since no other UIDs and GIDs are static (except 0,
> which is embedded in the kernel design...). After all, that's why we
> have getpwuid()...
Agreed. The rest of the thread is junk but the basic initial question is a
good one - why was bin forced to 1 ?
Joerg Schilling
>From: Chris Lawrence <lawr...@debian.org>
>On Feb 19, Wichert Akkerman wrote:
>> Previously Chris Lawrence wrote:
>> > Will do. The uid/gid 1 issue is definitely an issue; Debian probably
>> > can't make that change, and I suspect many other LSB implementations
>> > would trip over it too if they have any POSIX already.
>>
>> We can just drop most of the standard accounts and become compatible
>> by simply not having an optional account. Most of bin/daemon/sync/etc.
>> aren't used anyway it seems.
>Unfortunately, the following accounts are required (per
>http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/usernames.html):
>USER GROUP UID GID
>root root 0 0
>bin bin 1 1
>daemon daemon X X
>X = unspecified
Daemon has always been 1 on all traditional UNIX versions including AT&T
and *BSD. The real problem between AT&T and *BSD was that
AT&T uses 2 for bin and 3 for sys
while
*BSD used 3 for bin and 2 for sys.
Also note that on SunOS 3.x and 4.x "nonody"/"nogroup" have been 65534 \**
while SunOS 5.x and SYSvr4 defines "nonody"/"nogroup" to be 60001
and in addition introduce "noaccess" with 60002.
**) BSD seems to have copied over the old SunOS nobody mapping.
NOTE: If you ever plan to share e.g. /usr via NFS in order to have e.g
discless or dataless clients you need to aggree on a static map for
all system relevant IDs.
Also note: if you like to use a recent TAR standard format \**
for data exchange there is a need to standardize nobody/nogroup for security
reasons. If you don't standardize nobody/nogroup, you need at least
forbid 65534 & 60001/60002 for regular users.
Note that many people run file servers with a passwd file that does not
hold uid information for the users on the NFS clients. It you make backups,
there then is only numeric ID information. As you must take care people who use
outdated TAR implementations (like the "pax" implementaion recommended by
Mr. Kukuck from SuSE), keep in mind that those implementations do not support
POSIX.1-2001 extended headers like "star" and thus will not understand them.
They will only see the 7x3 bit values from the old TAR header. For this reason
it is important that in case you are archiving ID values > 2097151 you need to
use the value of "nobody" for the small number in the old TAR header.
If you don't, you will end up to see the real ID modulo 2097151 which may be a
real secority problem in case the files have TSUID or TSGID bit set in the
permissions.
OK, let me stop here and see if there is the right audience on this group
before I probably waste my time while writing mail....
**) It seems that at least Mr. Kukuck from SuSE decided to use a "pax"
implementation which only supports the 1990 POSIX standard, so there cannot be
Large File support or support for UID/GID > 2097151 on LSB Linux.
>On Debian:
>USER GROUP UID GID
>root root 0 0
>bin bin 2 2
>daemon daemon 1 1
This is funny and not somilar to any traditional UNIX system - why?
Jörg
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
Joerg Schilling
>> IIRC, I think the reasoning went as follows:
>> - The LSB format is based on RPM which has a CPIO archive
>> - CPIO archives store uid/gids as numbers, not names
>RPM does not have that limitation
>> - Hence the daemon user must have a fixed uid
>RPM does not have that limitation either
>> Note that once the program is running, it can use getpwent(). We're talking
>Doesn't help you - the password file is not the first package installed on
>a typical distro
So RPM _has_ that limitation....
Joerg Schilling
>> Frankly, I can't see any reason why uid/gid 1 should be assumed to be
>> bin, especially since no other UIDs and GIDs are static (except 0,
>> which is embedded in the kernel design...). After all, that's why we
>> have getpwuid()...
>Agreed. The rest of the thread is junk but the basic initial question is a
>good one - why was bin forced to 1 ?
In principle there is no reason to force a specifiv number.
However there is a reason to force identical numbers to allow NFS mounting of /usr.
If you decide on the numbers it would probably make sense to check the SYSvr4
passwd file because most commercial UNIX versions out use this mapping.
root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
smmsp:x:25:25:SendMail Message Submission Program:/:
listen:x:37:4:Network Admin:/usr/net/nls:
nobody:x:60001:60001:Nobody:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x Nobody:/:
and for group:
root::0:root
other::1:
bin::2:root,bin,daemon
sys::3:root,bin,sys,adm
adm::4:root,adm,daemon
uucp::5:root,uucp
mail::6:root
tty::7:root,adm
lp::8:root,lp,adm
nuucp::9:root,nuucp
staff::10:
daemon::12:root,daemon
sysadmin::14:
smmsp::25:smmsp
nobody::60001:
noaccess::60002:
nogroup::65534:
Alan Cox
> >good one - why was bin forced to 1 ?
>
> In principle there is no reason to force a specifiv number.
> However there is a reason to force identical numbers to allow NFS mounting of
> /usr.
No. Thats an argument for not forcing them in fact. If they are not dictated
then you can pick an arbitary mapping and use that. Which means whatever
legacy setup you have (providing it has no existing clashes) will work.
Specifying entries just ensures you screw somebody
Alan Cox
>
> >Doesn't help you - the password file is not the first package installed on
> >a typical distro
>
> So RPM _has_ that limitation....
With a postinstall trigger - no.
Andrew Pimlott
> - Installed programs may want to use the daemon user
LSB programs? I don't see what justification they would have for
doing so, since the daemon user is specified as "Subprocess special
privileges", whatever that means. I think it would be much cleaner
to specify that LSB programs should create their own users for
daemon processes. (useradd is in LSB, and separate uids is better
for security.)
Similarly with bin: "Administrative user with some restrictions"
doesn't tell me anything about how I, as a packager of an LSB
program, would use it. Further, Debian has had user bin forever
(probably for the same reason as the LSB: vague tradition), yet
AFAICT has found absolutely no use for it.
Why can't we end-around this whole issue by dropping these users
from the LSB?
This is the bug I filed:
http://sourceforge.net/tracker/index.php?func=detail&aid=451195&group_id=1107&atid=101107
Andrew
Wichert Akkerman
> Why can't we end-around this whole issue by dropping these users
> from the LSB?
Very much agreed. We shouldn't have a single user or group in the spec
unless we have a very good reason (and example) for them. Vague
descriptions and things like `tradition' don't count. Personally
I'm not aware of a single use of the daemon, bin or sys accounts
and wouldn't mind dropping them. The less users we have the better.
(accounts that is, you know what I mean :)
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Joerg Schilling
>From al...@lxorguk.ukuu.org.uk Tue Feb 19 15:05:04 2002
>> >Agreed. The rest of the thread is junk but the basic initial question is a
>> >good one - why was bin forced to 1 ?
>>
>> In principle there is no reason to force a specifiv number.
>> However there is a reason to force identical numbers to allow NFS mounting of
>> /usr.
>No. Thats an argument for not forcing them in fact. If they are not dictated
>then you can pick an arbitary mapping and use that. Which means whatever
>legacy setup you have (providing it has no existing clashes) will work.
If you cannot rely on hardcoded numbers, then it will not work to NFS mount /usr
bewteen different distributions.
This looks much like you are not taking LSB for serious.
Note that neither NFS v1, nor V2 or v3 do contain any precautions to map user
ids.
Jörg
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
Wichert Akkerman
> If you cannot rely on hardcoded numbers, then it will not work to NFS
> mount /usr bewteen different distributions.
You already can not, as was demonstrated not all Linux distributions
use the same uid/gid for these users.
Question is: why should you rely on having these users provided by
the LSB? They don't serve any purpose (at least not within LSB).
If people need them in their environment there is nothing to stop them
from (re)creating them with a consistent uid/gid that is consistent
throughout their environment.
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Alan Cox
> >then you can pick an arbitary mapping and use that. Which means whatever
> >legacy setup you have (providing it has no existing clashes) will work.
>
> If you cannot rely on hardcoded numbers, then it will not work to NFS mount /usr
> bewteen different distributions.
You can fix the numbers on any system to match what you want. Thats what not
defining numbers means. "I've got 8 legacy sun boxes so I'll use their
system uid layout"
> Note that neither NFS v1, nor V2 or v3 do contain any precautions to map user
> ids.
They don't disallow it either. See uuid in the unfsd package
Steve Langasek
> > Note that once the program is running, it can use getpwent(). We're talking
> Doesn't help you - the password file is not the first package installed on
> a typical distro
So the goal of this provision is to allow LSB packages to make use of
certain non-root facilities before the system has a password file?
I'd think the easy way to avoid that nonsense is to specify that an
LSB-compliant system gives meaningful results when calling getpwnam()
for certain required usernames (whether it uses /etc/passwd, NIS, LDAP,
whatever). That one issue doesn't justify hard-coding of
arbitrarily-chosen uids for system users.
In Debian, our /etc/passwd is provided by base-passwd, which is an
"Essential: yes" package of required priority that's part of the base
section of the archive. Anyone trying to install an LSB package on
Debian before the *installer* has even been allowed to run is engaged in
foot-shooting of Olympic proportions.
While I don't know whether Debian would be considered a 'typical'
distro, I would expect that other common distros are similarly
unaffected by this concern.
Steve Langasek
postmodern programmer
Alan Cox
> > a typical distro
>
> certain non-root facilities before the system has a password file?
Its not needed for that either. Nothing in an RPM based system that I know
of requires bin is uid 1
Christopher Yeoh
> > > Doesn't help you - the password file is not the first package installed on
> > > a typical distro
> >
> > So the goal of this provision is to allow LSB packages to make use of=20
> > certain non-root facilities before the system has a password file?
>
> Its not needed for that either. Nothing in an RPM based system that I know
> of requires bin is uid 1
So does anyone out there have any objections to removing the
requirement that the uid and gid of the bin user be 1? If no one
comes up with a good reason in the next week I'll just remove it.
Chris
--
cy...@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia
Wichert Akkerman
> So does anyone out there have any objections to removing the
> requirement that the uid and gid of the bin user be 1? If no one
> comes up with a good reason in the next week I'll just remove it.
Why keep the bin user at all? I haven't seen a rationale for its
existence yet.
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Stuart Anderson
> So does anyone out there have any objections to removing the
> requirement that the uid and gid of the bin user be 1?
We put it in there for a reason, and so far, I don't think anyone has
correctly recalled the reason. Unfortunately, it was done so long ago that
I don't remember all of the details either.
I think part of the reason for having added this was that this was an area
where divergence was beginning to occur, and those participating at the time
felt that we should specify the common practice to prevent further divergence.
Before we make a change here, some one should look through the archive, and
try to summarize the discussions that let to it being added in the first place.
> If no one
> comes up with a good reason in the next week I'll just remove it.
Unfortunately, we can't just remove it. It has been published as part
of the standard. What we can do, however, is to mark that portion as
"deprecated" and remove it in a future release.
Stuart
Stuart R. Anderson ande...@metrolink.com
Metro Link Incorporated South Carolina Office
5807 North Andrews Way 129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.660.2500 voice: 803.951.3630
http://www.metrolink.com/ XFree86 Core Team
Anthony Towns
> We put it in there for a reason, and so far, I don't think anyone has
> correctly recalled the reason. Unfortunately, it was done so long ago that
> I don't remember all of the details either.
You know, if no one can think of the reason in the months since this
was first brought up in response to the "1.0" spec release, it quite
simply can't have been a remotely good one. It's already evident that
absolutely *none* of the stake holders in the LSB have any particular
interest in keeping it, and a number of important stakeholders (Debian,
you know, the second or third most popular Linux distribution worldwide,
and everyone who wants their LSB compliant packages to run on Debian; not
to mention Solaris ("Sun's implementation of Linux", if you'll recall))
have a strong desire to have it removed.
> I think part of the reason for having added this was that this was an area
> where divergence was beginning to occur, and those participating at the time
> felt that we should specify the common practice to prevent further divergence.
Preventing divergence is not the LSB's charter. The LSB's charter is
to specify a set of APIs that will allow useful third party software
to run across a wide variety of systems. Specifying the uid of the bin
user does not make it easier to write software for Linux systems, and
it limits the number of systems on which LSB-compliant software can run.
> Unfortunately, we can't just remove it. It has been published as part
> of the standard. What we can do, however, is to mark that portion as
> "deprecated" and remove it in a future release.
The standard is recognised to be buggy and there is no existing userbase.
What better time do you think there'll be to remove it?
Of course, I suppose you could argue that if the standard is kept buggy,
there probably won't ever be a userbase. Do you really want to?
Enough with going around in circles about pointless nonsense. There are
a handful of simple changes that are needed right now for the LSB to
achieve its goals. It's time to make them.
Who has commit access to version 1.2 of the spec?
Cheers,
aj
--
Anthony Towns <a...@humbug.org.au> <http://azure.humbug.org.au/~aj/>
We came. We Saw. We Conferenced. http://linux.conf.au/
``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
Wichert Akkerman
> I think part of the reason for having added this was that this was an area
> where divergence was beginning to occur, and those participating at the time
> felt that we should specify the common practice to prevent further divergence.
I don't think divergence is a good reason for putting them into LSB:
if we don't spec those users at all it doesn't matter if they diverge
since people can't use them without violating the LSB, but more
interestingly it will also allow us to remove them completely.
> Unfortunately, we can't just remove it. It has been published as part
> of the standard. What we can do, however, is to mark that portion as
> "deprecated" and remove it in a future release.
What I plan to do for Debian is not install those users on new installs
but keep them around on existing systems. This will be done after the
woody release though so it won't affect anyone for the current
forseeable future.
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
VomLehn, David
bin has uid/gid of 1, I would suspect that some application
installations use 1 as the bin uid/gid instead of looking it up. This
may not be good practices, but the LSB work is primarily focused on
codifying current practices, good or not.
Before this is deprecated, it would probably help to look in
distributions of various application packages and/or ask the
creators/maintainers of those packages to check for an assumption that
bin will have uid/gid equal to 1. And, since we all make mistakes, I'd
suggest changing the bin uid/gid on a system in a distribution or two,
install the most commonly used applications, and see if they execute
properly.
Wichert.
--
To UNSUBSCRIBE, email to lsb-spec...@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email
listm...@lists.linuxbase.org
Stuart Anderson
> You know, if no one can think of the reason in the months since this
> was first brought up in response to the "1.0" spec release, it quite
> simply can't have been a remotely good one.
The words in question were written well over a year ago, which is why it
is hard to recall the details.
> It's already evident that
> absolutely *none* of the stake holders in the LSB have any particular
> interest in keeping it, and a number of important stakeholders (Debian,
> you know, the second or third most popular Linux distribution worldwide,
Yes, I am quite familiar with Debian as I use it in several places.
> and everyone who wants their LSB compliant packages to run on Debian; not
> to mention Solaris ("Sun's implementation of Linux", if you'll recall))
> have a strong desire to have it removed.
I don't mind removing it, but I do mind making random, uncontrolled changes
to a document that is supposed to be stable and "controlled". My point in this
is that we need to follow a proper process in making changes like this.
> Preventing divergence is not the LSB's charter.
Actually, it is one of the original problems that cuased the LSB to be formed
nearly 4 years ago.
> The LSB's charter is
> to specify a set of APIs that will allow useful third party software
> to run across a wide variety of systems.
Developing the ABI for Linux was seen as the best route to accomplishing
the job. Adding a few things beyond the strict limits of the ABI was also
seen as a good thing.
> Specifying the uid of the bin
> user does not make it easier to write software for Linux systems, and
> it limits the number of systems on which LSB-compliant software can run.
As I said above, I don't mind removing the uids, I just want to make sure that
proper diligence is used when doing so.
> The standard is recognised to be buggy and there is no existing userbase.
> What better time do you think there'll be to remove it?
I'm not resisting the removal of it, just that a proper process be followed.
This avoids having to ask the questions "how large does the user base have
to be before we can't fix something".
> Of course, I suppose you could argue that if the standard is kept buggy,
> there probably won't ever be a userbase. Do you really want to?
I have never suggested keeping it buggy.
> Enough with going around in circles about pointless nonsense. There are
> a handful of simple changes that are needed right now for the LSB to
> achieve its goals. It's time to make them.
>
> Who has commit access to version 1.2 of the spec?
Myself and a few others, but I have been tasked with ensuring that changes are
made in a consistant manner. That's all I am trying to do.
Stuart
Stuart R. Anderson ande...@metrolink.com
Metro Link Incorporated South Carolina Office
5807 North Andrews Way 129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.660.2500 voice: 803.951.3630
http://www.metrolink.com/ XFree86 Core Team
Stuart Anderson
> I don't think divergence is a good reason for putting them into LSB:
> if we don't spec those users at all it doesn't matter if they diverge
> since people can't use them without violating the LSB, but more
> interestingly it will also allow us to remove them completely.
There was some original problem that was caused by the fact they were
different on different distributions. I would just like to be able to
recall what that problem was, and then we can decide if it still needs
fixing or not.
Stuart
Stuart R. Anderson ande...@metrolink.com
Metro Link Incorporated South Carolina Office
5807 North Andrews Way 129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.660.2500 voice: 803.951.3630
http://www.metrolink.com/ XFree86 Core Team
Anthony Towns
> I would urge some caution here. If I were to guess at a reason as to why
> bin has uid/gid of 1, I would suspect that some application
> installations use 1 as the bin uid/gid instead of looking it up. This
> may not be good practices, but the LSB work is primarily focused on
> codifying current practices, good or not.
No, it's not. The LSB is focussed on codifying practices that can be used
to install third party software on any distribution of Linux. Assuming
the uid of the bin user is 1, is not one of those practices, and it
should never have been codified.
This change will not make any distribution non-conformant, and since
there are absolutely no LSB compliant apps at present, won't break any
of them, either.
Wichert Akkerman
> I would urge some caution here. If I were to guess at a reason as to why
> bin has uid/gid of 1, I would suspect that some application
> installations use 1 as the bin uid/gid instead of looking it up.
But this already isn't portable since the uid of bin is not consistent
between Linux distributions.
> This may not be good practices, but the LSB work is primarily focused
> on codifying current practices, good or not.
codifying a current broken practice is broken. Also notice that the
description if bin and daemon in the LSB are vague at best which
suggests that there really is nobody who has any good reason for
having those accounts around.
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
--
VomLehn, David
consistent between Linux distributions. That's not the issue and Debian
is not going to comply with LSB 1.0, ever. But note that I am saying
nothing about complying with any other version of the LSB.
The most difficult question that a standards body codifying existing
practice deals with is trying to not break existing software. Since most
software should be using good practices and hence using getpwent(), most
existing software will work with Debian. When we deprecate a specific
item in the LSB, we are giving software providers notice that their
software needs to be changed to comply with LSB 1.x, 2.x, etc. When the
specification requirement that bin's uid/gid be 1 is obsoleted, software
providers will have been given ample time (1-2 yrs.?) to update their
software. At that time, Debian, with no changes, will become compliant
with the version of the LSB in which the requirement that bin's uid/gid
be 1 is dropped.
If I were Debian, I would be frustrated at the length of time it takes
to obsolete a feature. It's an unfortunate reality that software
producers need to have time to change their products, but it is also an
unavoidable reality.
Lastly, I offer the observation that if it were easy to create and
update a Linux interface standard, it would have been done a long time
ago.
-----Original Message-----
From: Wichert Akkerman [mailto:wic...@wiggy.net]
Sent: Wednesday, February 20, 2002 9:19 AM
To: VomLehn, David
Cc: debian...@lists.debian.org; lsb-...@lists.linuxbase.org
Subject: Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core
support package
Josip Rodin
> > Preventing divergence is not the LSB's charter.
>
> Actually, it is one of the original problems that cuased the LSB to be formed
> nearly 4 years ago.
I think he meant "preventing divergence that doesn't need prevention is no
the charter of LSB".
> I'm not resisting the removal of it, just that a proper process be followed.
> I have been tasked with ensuring that changes are made in a consistant
> manner. That's all I am trying to do.
Okay, so let's summarize. This rule breaks things as it is. If we change it,
other things might break. However, nobody can think of what these other
things are. The choice seems pretty clear, now let's start the procedure of
changing. :)
--
2. That which causes joy or happiness.
Wichert Akkerman
> That's not the issue and Debian is not going to comply with LSB 1.0,
> ever.
From what I see no distribution will be LSB 1.0 complient but will
start with 1.1 instead. But that isn't really relevant here.
> The most difficult question that a standards body codifying existing
> practice deals with is trying to not break existing software.
Mostly agreed.
> If I were Debian, I would be frustrated at the length of time it takes
> to obsolete a feature.
That isn't frustrating. Debian has always been in the business of
providing seemless upgrades and we've been dealing with numerous
multi-year transitions forever so we know how that works.
The frustrating bit is that apparently these users were added to the LSB
without a clear rationale and we need to clean up the resulting mess
now.
> It's an unfortunate reality that software producers need to have time
> to change their products, but it is also an unavoidable reality.
Can we try and investigate if there is a product out there that
actually uses these two users? I would be very surprised of one
exists.
> Lastly, I offer the observation that if it were easy to create and
> update a Linux interface standard, it would have been done a long time
> ago.
That isn't going to stop anyone from complaining though :)
Stuart Anderson
> I think he meant "preventing divergence that doesn't need prevention is no
> the charter of LSB".
I can agree with that.
At the time (over a year ago), those participating in the LSB work felt that
is was needed, so it got added. I agree, that it probably isn't needed, and
just want to back it out in an appropriate manner.
> Okay, so let's summarize. This rule breaks things as it is. If we change it,
> other things might break. However, nobody can think of what these other
> things are. The choice seems pretty clear, now let's start the procedure of
> changing. :)
OK 8-). I do feel that part of the proceedure is to understand why it was
added in the first place. The only thing worse than having it in there, would
be to remove it, and then discover the hard way why it had been put in there
to begin with.
Stuart
Stuart R. Anderson ande...@metrolink.com
Metro Link Incorporated South Carolina Office
5807 North Andrews Way 129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.660.2500 voice: 803.951.3630
http://www.metrolink.com/ XFree86 Core Team
VomLehn, David
-----Original
Message-----
From: Anthony Towns [mailto:a...@azure.humbug.org.au]
Sent:
Wednesday, February 20, 2002 9:18 AM
To: debian...@lists.debian.org;
lsb-...@lists.linuxbase.org
Subject: Re: Bug#134658: ITP: lsb -- Linux
Standard Base 1.1 core
support package
On Wed, Feb 20, 2002 at
09:11:14AM -0600, VomLehn, David wrote:
> I would urge some caution here.
If I were to guess at a reason as to why
> bin has uid/gid of 1, I would
suspect that some application
> installations use 1 as the bin uid/gid instead of looking it up. This
> may not be good practices, but the LSB
work is primarily focused on
> codifying current practices, good or
not.
No, it's not. The LSB is focussed on codifying practices that can be
used
to install third party software on any distribution of Linux.
Assuming
the uid of the bin user is 1, is not one of those practices, and
it
should never have been codified.
Yes, and I think it's likely we made a mistake. It's now too late to change that for versions 1.0 and 1.1 of the LSB specification and I suggest that we simply understand the current state of affairs, accept it, and implement a reasonable process to fix the mistake. Doing so will take at least a year after the fix process begins to allow any application providers to make the required change.The fix for this follows a well-beaten path--we are not the first standardization body to make a mistake. Assuming there is nobody who can find any reason for the current state of affairs, the very next release of the LSB includes, 1) a statement that the requirement that uid and gid be one is deprecated and will become obsolete in a future release, 2) specify that the plan is to obsolete this requirement in the first approved version of the LSB specification after a particular date, and 3) deliver on item 2.
This change will not make any distribution
non-conformant, and since
there are absolutely no LSB compliant apps at
present, won't break any
of them, either.
Yes, and it's great when we can move forward without breaking anything. The fact that there are no LSB compliant applications at present does not mean that there are no applications which completely meet the LSB specification. When a proper validation procedure exists for formally declaring an application compliant with LSB 1.1, the ones which assume that the uid and gid of bin are one will also be compliant. Since I expect the LSB effort to continue into the future, I also expect that some LSB 1.1 compliant applications will not be LSB compliant to a future version of the specification.
I think I've made my position clear, so I have nothing further to discuss on this issue in LSB mailing lists. If anyone else wishes to engage me in further dialog, please send email directly to me. If there is a reason to view things differently, I'll publicize it myself.
c...@maine.com
> On Wed, Feb 20, 2002 at 10:15:03AM -0500, Stuart Anderson wrote:
> > > Preventing divergence is not the LSB's charter.
> >
> > Actually, it is one of the original problems that cuased the LSB to be formed
> > nearly 4 years ago.
>
> I think he meant "preventing divergence that doesn't need prevention is no
> the charter of LSB".
>
> > I'm not resisting the removal of it, just that a proper process be followed.
>
> > I have been tasked with ensuring that changes are made in a consistant
> > manner. That's all I am trying to do.
>
> Okay, so let's summarize. This rule breaks things as it is. If we change it,
> other things might break. However, nobody can think of what these other
> things are. The choice seems pretty clear, now let's start the procedure of
> changing. :)
Re bin being UID 1/1:
Our systems are legacy Slackware A-E set (or maybe mangle mode circa '94)
converted to debian. We've never gotten around to changing some of the < 100
userids and still have bin as 2/2. Not changing has not broken anything.
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
cfm
--
Christopher F. Miller, Publisher c...@maine.com
MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039
1.207.657.5078 http://www.maine.com/
Content/site management, online commerce, internet integration, Debian linux
Wichmann, Mats D
Anthony Towns
> > You know, if no one can think of the reason in the months since this
> > was first brought up in response to the "1.0" spec release, it quite
> > simply can't have been a remotely good one.
> The words in question were written well over a year ago, which is why it
> is hard to recall the details.
Well, it's over half a year since this
was first brought up as a problem (4 July 2001,
http://lists.debian.org/lsb-spec/2001/lsb-spec-200107/msg00002.html at
the very least).
> I don't mind removing it, but I do mind making random, uncontrolled changes
> to a document that is supposed to be stable and "controlled". My point in this
> is that we need to follow a proper process in making changes like this.
Well, it'd have been nice if that had happened in the first place, with,
say, some reasonable opportunity to comment on things like this *before*
they were specified. But since that didn't happen, the LSB simply has
to fix it now, however galling that may be.
> > Specifying the uid of the bin
> > user does not make it easier to write software for Linux systems, and
> > it limits the number of systems on which LSB-compliant software can run.
> As I said above, I don't mind removing the uids, I just want to make sure that
> proper diligence is used when doing so.
What, exactly, is "proper diligence" ?
It would seem to me that due diligence would involve contacting key
distribution vendors (Red Hat, Debian, Mandrake, SuSE) and ensuring there
are no issues with a change. This clearly was *not* done before the bin
uid was added to the 1.0 spec (the change wasn't even mentioned on the
list before the 1.0 spec was released); and it clearly *has* been done now
(there are developers from all of those distributions on the LSB specs,
and developers from at least two of them have commented in favour of
the change).
By contrast, where was the due diligence in response to 496591 ("LSB
packages should be named ".lsb")? The only response I've seen to that
(and since I raised the issue, I'd assume I'd see what response there
is), was the thread beginning at:
http://lists.debian.org/lsb-discuss/2001/lsb-discuss-200112/msg00035.html
and a "discussed and rejected" response to the sourceforge bug report,
and in one of the conference call minutes. If you look back through
the thread, you'll see absolutely no consensus or meeting of minds was
achieved.
There are a host of other issues that I and others have raised which
have been dealt with in a similarly haphazard way (hardcoding Red Hat's
interpretation of runlevels into the init script spec, the useless "local
mounts" and "remote mount" system services, to name a couple of examples).
These aren't things that kill the spec (unlike a number of the details
in the user/group spec), but they are detrimental. The LSB group is
doing a fine job of ignoring them all out of existance, though.
> > The standard is recognised to be buggy and there is no existing userbase.
> > What better time do you think there'll be to remove it?
> I'm not resisting the removal of it, just that a proper process be followed.
So forgive me if these words ring completely hollow. [0]
> > Enough with going around in circles about pointless nonsense. There are
> > a handful of simple changes that are needed right now for the LSB to
> > achieve its goals. It's time to make them.
> > Who has commit access to version 1.2 of the spec?
> Myself and a few others, but I have been tasked with ensuring that changes are
> made in a consistant manner. That's all I am trying to do.
Well, I'm not sure I can dispute the consistency of the change policy
("Oh, it's from Debian, eh? Ignore it."), but ensuring necessary or
useful changes are made quickly and correctly seems like a much more
worthy goal.
It's not really fun watching a project that seems like it could be fairly
important to the Linux community falling into all the usual traps of
non-bazaar development [0].
Cheers,
aj
[0] Process over functionality. Unresponsiveness to comments. Closed
channels of communication between the core developers instead of
regular use of mailing lists. Worrying more about releasing at
LinuxWorld than getting something useful, or at least, not actively
harmful, out.
Anthony Towns
> It's now too late to change
> that for versions 1.0 and 1.1 of the LSB specification
I know no one's going to actually listen to me here, but it bears
repeating: this is quite simply wrong.
It's our spec. We can do whatever we like to it. We can declare that
packages written by people whose middle name has an odd number of
letters were never intended to comply with the specs, and issue updates
to both version 1.0 and 1.1 tomorrow to say that. No one is going to stop
us. We're not going to be thrown in prison. We're not going to have our
editors or our web pages taken away from us.
More to the point: we're not even going to annoy anyone. Of the
distributors who've started trying to conform to the LSB, *none* of them
will have to change anything. Any application developers who've been
writing LSB packages will be pleased to have been informed of what they
have to do to make sure their programs actually run on Debian. People
writing test suites will have one less thing to try to test, so they'll
be overjoyed.
We could do this tomorrow, and _no one_ would have any cause to complain.
Of course, the *real* lesson to learn from this is *NEVER* *EVER* to
make an official release without having a thorough round of reviews and
actually resolving all the issues that're raised, no matter how long
this takes. The uid-of-user-bin issue was raised as soon as we saw the
form that section took, which unfortunately was immediately after the
1.0 spec was published, and during the review period for the 1.1 spec.
Cheers,
aj
Chris Lawrence
> The fix for this follows a well-beaten path--we are not the first
> standardization body to make a mistake. Assuming there is nobody who can
> find any reason for the current state of affairs, the very next release
> of the LSB includes, 1) a statement that the requirement that uid and
> gid be one is deprecated and will become obsolete in a future release,
> 2) specify that the plan is to obsolete this requirement in the first
> approved version of the LSB specification after a particular date, and
> 3) deliver on item 2.
Sounds reasonable enough to me, I guess. I think our main concern
over on the Debian side of the aisle is that this will be a sticking
point for conformance; we want to have LSB support, and we'd like to
be as close as possible to full support in woody, and be fully
conformant for woody+1. (Not that we officially have any woody+1
release goals beyond contining the pre-FHS symlink phaseout.)
Anyway, if people on the lsb-spec list want to see how close we are to
conformance (IMHO, of course ;-), the place to start is the start of
the thread (lsb-spec got on a few posts in):
http://lists.debian.org/debian-devel/2002/debian-devel-200202/msg01335.html
and what I have so far (including a few minor fixes) is:
http://people.debian.org/~lawrencc/lsb_1.1.0-2.tar.gz
Chris
--
Chris Lawrence <cnla...@phy.olemiss.edu> - http://www.lordsutch.com/chris/
Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi
125B Lewis Hall - 662-915-5765
Adam Lazur
> http://lists.debian.org/debian-devel/2002/debian-devel-200202/msg01335.html
>
> and what I have so far (including a few minor fixes) is:
>
> http://people.debian.org/~lawrencc/lsb_1.1.0-2.tar.gz
Regarding the init stuff:
Wouldn't it make more sense to add install_initd and remove_initd to the
sysvinit package (as they are sysv init specific)?
This would ease addition of an alternative package that provides init in
the future.
Also looking forward, it would be nice init-functions was a symlink or
something else changeable (alternative maybe) so the behavior is
pluggable.
--
Adam Lazur, Cluster Monkey
Wichert Akkerman
> Also looking forward, it would be nice init-functions was a symlink or
> something else changeable (alternative maybe) so the behavior is
> pluggable.
We could always divert it later on, no need to make it a symlink.
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Wichmann, Mats D
> On Wed, Feb 20, 2002 at 08:13:13AM -0800, Wichmann, Mats D wrote:
> > It's now too late to change
> > that for versions 1.0 and 1.1 of the LSB specification
I didn't, actually. That was David.
> Of course, the *real* lesson to learn from this is *NEVER* *EVER* to
> make an official release without having a thorough round of
> reviews
Which there was...
> and
> actually resolving all the issues that're raised, no matter how long
> this takes.
The participants seemed to agree that there needed to be a process
that included a finishing date. That process was followed, and there
was plenty of room to comment. Are there going to be "bugs" in
the result that are found when it's actually put into use? Of course,
like with any product.
Andrew Pimlott
> is hard to recall the details.
> I don't mind removing it, but I do mind making random, uncontrolled changes
> to a document that is supposed to be stable and "controlled". My point in this
> is that we need to follow a proper process in making changes like this.
I guess this will come off as smart, but if it is "controlled", I
would have expected someone to write down why this section was
written in the first place.
It sounds like the early versions were hastily slapped together
(this is not the only section that gives me this impression), yet
now you expect people to endure a painful process to make obviously
needed amendments.
Andrew
M. Drew Streib
> now you expect people to endure a painful process to make obviously
> needed amendments.
For the sake of forward movement, I'd like to suggest that we're not
far from total agreement here:
1) There may not be a good reason for requiring these users, and
especially at a particular uid.
2) We should investigate why the decision was made in the first place.
This is only due diligence. I would expect any distribution to do
the same before making a change that _potentially_ broke expected
behavior.
3) If we find that there wasn't a good reason for these users, or
that the reasons don't outweigh the 'brokenness' of requiring them,
they should be removed via the proper methods for standards revision.
Unfortunately, this isn't quite as easy as simply making the change,
as the first spec revisions, like it or not, are printed and labeled.
This doesn't mean that the change can't be made however.
Moving forward, it would seem most productive to simply find the
past discussion on this isssue, if any, then counter any decisions
made in the past with the discusion from the past couple of days.
It seems likely that this will result in a spec change, but
not pursuing at least a basic review of the facts (and history
of that part of the spec, if any) would be negligent.
-drew
--
M. Drew Streib <dt...@dtype.org>, Free Standards Group (freestandards.org)
co-founder, SourceForge.net | core team, freedb | sysadmin, Linux Intl.
creator, keyanalyze report | maintnr, *.us.pgp.net | other freedom/law
Stuart Anderson
> I guess this will come off as smart, but if it is "controlled", I
> would have expected someone to write down why this section was
> written in the first place.
Good point. In fact, how to maintain a rational as part of the document
was discussed. At the time, it didn't seem critical to include the rational
in the standards document. (You can have a good debate about wether rational
is appropriate for the normative parts of a standards). Anyway, because we
all learn from what we do, it now seems that having the rational would be
helpful.
> It sounds like the early versions were hastily slapped together
> (this is not the only section that gives me this impression),
There were fewer people contributing back then, so some section probably were
hastily written.
> yet
> now you expect people to endure a painful process to make obviously
> needed amendments.
It doesn't have to be a painful process. I didn't mean to imply that it should
be, or even that is has to be a heavy process, only that some process must
be followed. Changing the document simply because write access is available
is not an appropriate process.
I think we've demonstrated that there is concensus that the change should be
made. I agree with that.
I do think that before removing or deprecating something we should make sure
we understand why it was added in the first place. If the answer is that it
was rushed and overlooked in the beginning, then that's fine. If there is some
other reason, then we need to be sure that we have considered it.
Once this is done, then we can change the wording in the spec to indicate that
is is deprecated.
Stuart
Stuart R. Anderson ande...@metrolink.com
Metro Link Incorporated South Carolina Office
5807 North Andrews Way 129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.660.2500 voice: 803.951.3630
http://www.metrolink.com/ XFree86 Core Team
Chris Lawrence
> Chris Lawrence (lawr...@debian.org) said:
> > http://lists.debian.org/debian-devel/2002/debian-devel-200202/msg01335.html
> >
> > and what I have so far (including a few minor fixes) is:
> >
> > http://people.debian.org/~lawrencc/lsb_1.1.0-2.tar.gz
>
> Regarding the init stuff:
>
> Wouldn't it make more sense to add install_initd and remove_initd to the
> sysvinit package (as they are sysv init specific)?
>
> This would ease addition of an alternative package that provides init in
> the future.
Actually, they use the defined interface to init, so they should work
with any init that supports update-rc.d (per policy). The readme may
be overspecific on this point by referring to sysvinit.
> Also looking forward, it would be nice init-functions was a symlink or
> something else changeable (alternative maybe) so the behavior is
> pluggable.
Well, ideally init-functions should call some nice pluggable stuff for
the output logging, if we come up with an init logging policy for
woody+1 (it's been talked about, but nobody to my knowledge has said
"I have an implementation" that we can play with).
My gut feeling is that init-functions *itself* should stay in the lsb
package, because it has to conform with LSB practice. I really don't
think it's a good idea for $random_debian_package to use the LSB
interface, as it's pretty lame compared to start-stop-daemon.
Chris
--
Chris Lawrence <cnla...@phy.olemiss.edu> - http://www.lordsutch.com/chris/
Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi
125B Lewis Hall - 662-915-5765
Chris Lawrence
> On Wed, 20 Feb 2002, Andrew Pimlott wrote:
>
> > I guess this will come off as smart, but if it is "controlled", I
> > would have expected someone to write down why this section was
> > written in the first place.
>
> Good point. In fact, how to maintain a rational as part of the document
> was discussed. At the time, it didn't seem critical to include the rational
> in the standards document. (You can have a good debate about wether rational
> is appropriate for the normative parts of a standards). Anyway, because we
> all learn from what we do, it now seems that having the rational would be
> helpful.
If nothing else, a rationale would help flesh things out for people
doing a clean-room implementation. I for one was mystified about the
init runlevel section, and also had trouble figuring out what was
supposed to apply just to LSB *applications* and what applies to LSB
implementations. (For example, do all init scripts on a system have
to comply with LSB's specification, i.e. regarding return codes and
arguments, or just the ones provided by LSB conforming applications?)
Rationale would clear some of this stuff up. (i.e. "We required the
status argument because some distributions have tools that depend on
it." versus "We required the status argument because some applications
need to learn the state of services started by init.")
Chris
--
Chris Lawrence <cnla...@phy.olemiss.edu> - http://www.lordsutch.com/chris/
Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi
125B Lewis Hall - 662-915-5765
Trond Eivind Glomsrød
> On Wed, Feb 20, 2002 at 08:13:13AM -0800, Wichmann, Mats D wrote:
> > It's now too late to change
> > that for versions 1.0 and 1.1 of the LSB specification
>
> I know no one's going to actually listen to me here, but it bears
> repeating: this is quite simply wrong.
>
> It's our spec. We can do whatever we like to it. We can declare that
> packages written by people whose middle name has an odd number of
> letters were never intended to comply with the specs, and issue updates
> to both version 1.0 and 1.1 tomorrow to say that. No one is going to stop
> us. We're not going to be thrown in prison. We're not going to have our
> editors or our web pages taken away from us.
>
> More to the point: we're not even going to annoy anyone. Of the
> distributors who've started trying to conform to the LSB, *none* of them
> will have to change anything. Any application developers who've been
> writing LSB packages will be pleased to have been informed of what they
> have to do to make sure their programs actually run on Debian.
They don't care about running on Debian - at least, they shouldn't. If
they have written a program using this part of LSB 1.0, it shouldn't
matter if it's Debian, Slackware or Caldera they are running on if
these distribution claim to implement the standard. If they don't
claim to implement it, the program isn't expected to run anyway.
Any revision of the standard shouldn't go through overnight, but be in
a future revision after being carefully reviewed, and a rationale for
the change should be given (as it should have for being in there in
the first place).
> We could do this tomorrow, and _no one_ would have any cause to
> complain.
Anyone using it (developers, book printers, etc) would have cause.
--
Trond Eivind Glomsrød
Red Hat, Inc.
Stuart Anderson
Anthony,
First off, I'd like to say that I appreciate your diligence in poking
us with these issues. Because we are all human, we can only deal with so many
things at once, and as a result stuff falls through the cracks. If it weren't
for you and others that continue to champion these issues, we would be stuck
with some bad decisions.
We thought that we had things in place (such as the bug tracking
system on sourceforge) to help us ensure that things didn't fall through
the cracks. Apparently, though it has helped tremendously, we still have
problems with this. Now, before things get completely ramped up for the next
release of the spec, is a good time to examine these kinds of proceedure to
see how well they have worked. Since it is obvious that they haven't, I have
created and assigned to myself a Task to examing the bug processing proceedure
we have used. This proceedure should be more consensus based with a few more
checks and balances that we currently have.
One of the known issues that we have is the lack of a proper dispute
resolution mechanism. This is being worked on in a larger context, but is not
yet available.
Lacking a proper mechanism for this, if you can provide me the list
of bug numbers that you felt were inappropriately closed or rejected, I will
re-open them and ensure that they are properly addressed.
Stuart
Stuart R. Anderson ande...@metrolink.com
Metro Link Incorporated South Carolina Office
5807 North Andrews Way 129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.660.2500 voice: 803.951.3630
http://www.metrolink.com/ XFree86 Core Team
Shaya Potter
> On Wed, 20 Feb 2002, Andrew Pimlott wrote:
>
> > I guess this will come off as smart, but if it is "controlled", I
> > would have expected someone to write down why this section was
> > written in the first place.
>
> Good point. In fact, how to maintain a rational as part of the document
> was discussed. At the time, it didn't seem critical to include the rational
> in the standards document. (You can have a good debate about wether rational
> is appropriate for the normative parts of a standards). Anyway, because we
> all learn from what we do, it now seems that having the rational would be
> helpful.
rational as part of the spec document, would probably make the actuall
spec a little "wordy" (not sure of the right term). There should
perhaps be 2 documents, 1 would be the actual spec, the other would be
the spec + rational. This would also help avoid the traditional
disagreement in the meaning of the spec, as the "commentary" on the
"bible" (so to speak) would be readily available :)
Wichmann, Mats D
> spec a little "wordy" (not sure of the right term). There should
> perhaps be 2 documents, 1 would be the actual spec, the other would be
> the spec + rational. This would also help avoid the traditional
> disagreement in the meaning of the spec, as the "commentary" on the
> "bible" (so to speak) would be readily available :)
Rationale is often banished to the back of the document in
an appendix, or for a large volume, to a separate document.
Andrew Josey and others who've been through the mill several
times can probably comment more on the reasons for including/excluding
rationale. Certainly one con argument is that it makes more work since
the rationale also has to have carefully crafted wording, and choices
have to be made on what to include.
Personally, I would have found a rationale section very useful as
I came to this process quite late and the answer to certain
questions seemed on occasion to be "it's in the mail archive" - which,
as we've just seen from the number of posts on this thread - can mean
quite a bit of work to wade through - and may sometimes be buried under
a subject name that doesn't seem to relate if the dicussion has evolved.
Or to put it shorter, the historical record may be accurate, but it's
not necessarily concise or to the point.
Adam Lazur
> > This would ease addition of an alternative package that provides init in
> > the future.
>
> Actually, they use the defined interface to init, so they should work
> with any init that supports update-rc.d (per policy). The readme may
> be overspecific on this point by referring to sysvinit.
update-rc.d is SysV init specific.
So by including {install,remove}_initd in the lsb .deb and using
update-rc.d, Debian systems are limited to using Sys V init.
If you put install_initd and remove_initd in the actual package that
provides init, then another init system could easily plug in by
providing the lsb interface and _not_ the update-rc.d interface. (yes,
this would require removing update-rc.d from policy and making the
official way of adding an removing a bootup script to be the LSB way)
If you're not getting what I'm hinting at, I'd like to move away from
crappy SysV init and use something better in the future.
The LSB defining a sane way of genericizing init script installation and
removal without adding SysV inspired braindamage is a glimmer of hope
that one day I'll be able to use the NetBSD rc.d system [1] or Linux
boot scripts [2] with Debian, both of which suck substantially less than
SysV init.
> Well, ideally init-functions should call some nice pluggable stuff for
> the output logging, if we come up with an init logging policy for
> woody+1 (it's been talked about, but nobody to my knowledge has said
> "I have an implementation" that we can play with).
That's cool, as long as it's easily replaceable with a custom version.
Read on...
> My gut feeling is that init-functions *itself* should stay in the lsb
> package, because it has to conform with LSB practice. I really don't
> think it's a good idea for $random_debian_package to use the LSB
> interface, as it's pretty lame compared to start-stop-daemon.
I guess our views differ there.
IMO it's pretty lame that everybody rolls their own init script and adds
their own personal bugs when simple things like starting and stopping a
daemon could be centralized (like the LSB does). IMO it's also pretty
lame that any maintainer can spew data to the bootup screen in any way
they see fit.
The LSB functions allow for all of that stuff to be centralized and
stardardized. This is good. It makes everything behave the same way. It
also has the bonus of allowing replacements that conform the the API but
do things intentionally differently.
For example, RedHat has this sort of abstraction in their init scripts.
This allowed Sun to easily override those functions with ones that
display the startup status on the LCD of a cobalt box. This currently is
pretty near impossible to do on a Debian system, but it really shouldn't
be.
--
Adam Lazur, Cluster Monkey
[1] http://www.daemonnews.org/200108/rcdsystem.html
[2] http://www.atnf.csiro.au/~rgooch/linux/boot-scripts/
Martijn van Oosterhout
> Chris Lawrence (lawr...@debian.org) said:
> > with any init that supports update-rc.d (per policy). The readme may
> > be overspecific on this point by referring to sysvinit.
>
> update-rc.d is SysV init specific.
Actually, it's not. Perhaps you should lookup the debian package file-rc
which uses a file to handle the init scripts rather than sysVinit.
http://packages.debian.org/unstable/admin/file-rc.html
There are also other init machanisms supported. You could say that debian
was ahead of its time here.
> The LSB defining a sane way of genericizing init script installation and
> removal without adding SysV inspired braindamage is a glimmer of hope
> that one day I'll be able to use the NetBSD rc.d system [1] or Linux
> boot scripts [2] with Debian, both of which suck substantially less than
> SysV init.
update-rc.d is already generic. Check it out. Many people do indeed like it.
--
Martijn van Oosterhout <kle...@svana.org>
http://svana.org/kleptog/
> If the company that invents a cure for AIDS is expected to make their
> money back in 17 years, why can't we ask the same of the company that
> markets big-titted lip-syncing chicks and goddamn cartoon mice?
Adam Lazur
> On Wed, Feb 20, 2002 at 04:59:14PM -0500, Adam Lazur wrote:
> > update-rc.d is SysV init specific.
>
> Actually, it's not. Perhaps you should lookup the debian package file-rc
> which uses a file to handle the init scripts rather than sysVinit.
>
> http://packages.debian.org/unstable/admin/file-rc.html
Yes, I looked at that package before making the statement. They divert
update-rc.d and use their own hacked copy which does the translation to
a monolithic file.
update-rc.d's argument is the number which signifies the order in which
the script should be run on bootup. That's SysV init style.
Maybe you should read some of the links I posted as to why having a
meaningless number is not the best way?
> There are also other init machanisms supported. You could say that debian
> was ahead of its time here.
>
> update-rc.d is already generic. Check it out. Many people do indeed like it.
Could you please explain these statements?
Maybe I'm just too clueless to figure it out, but I don't consider that
since a script can be diverted that it should be considered generic.
--
Adam Lazur, Cluster Monkey
Henrique de Moraes Holschuh
> Yes, I looked at that package before making the statement. They divert
> update-rc.d and use their own hacked copy which does the translation to
> a monolithic file.
No. They divert update-rc.d and implement that *interface* to work with
whatever method of handling priorities they have.
This is not an ugly way of doing things. It works, and it is technically
sound a solution.
> update-rc.d's argument is the number which signifies the order in which
> the script should be run on bootup. That's SysV init style.
Yes. And it does not work at all for other types of initscript priority,
such as a dependency-based one. I suppose this is what you dislike.
> Maybe I'm just too clueless to figure it out, but I don't consider that
> since a script can be diverted that it should be considered generic.
update-rc.d isn't generic, but that has nothing to do with being diverted or
not...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Adam Lazur
> > update-rc.d's argument is the number which signifies the order in which
> > the script should be run on bootup. That's SysV init style.
>
> Yes. And it does not work at all for other types of initscript priority,
> such as a dependency-based one. I suppose this is what you dislike.
Correct. I'm saying that the API for update-rc.d does not allow for a
dependency based init system, but the LSB API _does_.
Furthermore I'm saying that a wrapper to translate from the LSB API to
the update-rc.d SysV tied one already exists (in the lsb .deb that was
posted).
> > Maybe I'm just too clueless to figure it out, but I don't consider that
> > since a script can be diverted that it should be considered generic.
>
> update-rc.d isn't generic, but that has nothing to do with being diverted or
> not...
Er, you conveniently cut the part where you state:
> update-rc.d is already generic. Check it out. Many people do indeed
> like it.
which is what I was responding to.
So it was generic in one post, now it's not. Thanks for agreeing with me
;)
--
Adam Lazur, Cluster Monkey
Anthony Towns
> They don't care about running on Debian - at least, they shouldn't.
You're confused.
ISV's using the LSB obviously care about running on Debian: they care about
running on as many platforms as possible to increase their potential market
share, either so they can make more money, or so they can be more famous.
What they don't want to do is have to special case us. If they follow
the LSB 1.0 or 1.1 specs, and make any use of the bin=uid 1 clause, then
they'll find they *will* have to special case us, and that will annoy
them, since the LSB's raison d'etre is to avoid that nonsense. Correcting
the spec allows us to avoid annoying them. Not correcting it buys no
one anything.
> If
> they have written a program using this part of LSB 1.0, it shouldn't
> matter if it's Debian, Slackware or Caldera they are running on if
> these distribution claim to implement the standard. If they don't
> claim to implement it, the program isn't expected to run anyway.
We're not designing this spec in a vacuum. There are real people out there
with real needs that we're trying to satisfy. If we're not satisfying
their needs now, we need to change it so we are. Debian is one set of
such people, ISVs who want their products to run on both Red Hat and
Debian are another.
Our aim is to let people say "Sure, my program will run on Linux. Doesn't
matter what flavour. Red Hat, SuSE, Debian, Slackware, heck, even BSD
or Solaris via the compatability layers." We're not aiming to have
people say "It'll run on Red Hat and SuSE. It won't run on Debian,
because although that's Linux, it's not *really* Linux". Or at least,
the people who I've talked to aren't.
> Any revision of the standard shouldn't go through overnight,
> but be in a future revision after being carefully reviewed,
> and a rationale for
> the change should be given (as it should have for being in there in
> the first place).
Sure. All of these things should happen. But they shouldn't be used as an
excuse to delay or block a necessary change for months (like has already
happened on this very issue) when the *original spec* had absolutely
none of these things.
> > We could do this tomorrow, and _no one_ would have any cause to
> > complain.
> Anyone using it (developers, book printers, etc) would have cause.
All those masses of developers shipping LSB 1.0 or 1.1 compliant software?
Or the masses of publishers who've already written whole chapters about
why uid 1 should be the bin user, even though we can't think of even a
sentence to justify it?
> Trond Eivind Glomsr?d
> Red Hat, Inc.
Of course, I suppose Red Hat does have a market incentive to make it
as difficult as possible for Debian to comply with the LSB.
"Oh, no, your products won't run on Debian, because those hacker wannabes
can't manage to comply with simple community developed standards. Better
buy Red Hat instead."
So I suppose someone does have a cause to complain afterall. My mistake.
Cheers,
aj, who'd be much less bitter if the last seven months had resulted in
pretty much anything other than "Oh, but Debian should suffer for
our art too, coz Red Hat did" (Hi, Chris), or "Yes, yes, interesting
point. But we must have a careful transition, and working out what
that would be like is on our todo list, so please don't bother
us now".
Christopher Yeoh
> aj, who'd be much less bitter if the last seven months had resulted in
> pretty much anything other than "Oh, but Debian should suffer for
> our art too, coz Red Hat did" (Hi, Chris), or "Yes, yes, interesting
Er. I never said that, I just pointed out that all the distributions
have had to do a fair amount of work to become compliant and Debian is
not alone in this regard.
Chris.
--
cy...@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia
David D.W. Downey
a question.
WHY does the LSB even _define_ numeric UID settings? For every distrib I've
used, Slackware, SuSe, Mandrake, Red Hat, Debian, Peanut, Stampede, and
others, any system user (meaning system related such as bin, adm, wheel, ect
ect) were always extrememly low UID numbers. This in turn signifies to the
system, as stated in the POSIX standard (don't shoot me if I'm wrong, been a
LONG time since I've read it), are reserved specificly for system related
accounts. These accounts have the required access privileges set up before
any distrib is relased, regardless of maker. So, if X for instances, needs
access to the video hardware (using sys or some other system defined
account) all one needs to do is set the permissions to that user.
Where the API would come in is in defining the test definition for
determining the right account to use, not the physical UID number.
If I am way off, don't fry me, this was a quick and dirty email for the
question as it popped into my head. I'm willing learn a lesson or two if I'm
off.
David D.W. Downey
-----Original Message-----
From: Christopher Yeoh [mailto:cy...@samba.org]
Sent: Wednesday, 20 February, 2002 6:56 PM
To: debian...@lists.debian.org; lsb-...@lists.linuxbase.org
Subject: Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core
support package
Joseph Carter
> > Okay, so let's summarize. This rule breaks things as it is. If we change it,
> > other things might break. However, nobody can think of what these other
> > things are. The choice seems pretty clear, now let's start the procedure of
> > changing. :)
>
> added in the first place. The only thing worse than having it in there, would
> be to remove it, and then discover the hard way why it had been put in there
> to begin with.
Thank you. It seems plainly obvious that this is necessary and I suspect
not many will object to so doing, but I have come to discover that when
dealing with groups you actually have to SAY these things now and then.
As for how some of the users and groups LSB proposes as standard got there
when nobody can seem to remember how or why, I can offer existing practice
as a reason. You may recall that two of the things discussed early in the
life of LSB were deployment to existing systems wherever practical and NFS
shares between LSB compliant systems. The latter, I recall, was shot down
for its impracticality when considering the former. They are explanation
enough for a number of things I have seen reconsidered by the LSB project
over the past few years. ;)
I don't have old list archives handy and am currently unable to search to
see if my memory happens to coincide neatly with reality yet. I doo seem
to remember this very discussion taking place over this very case long ago
now, so it is at least possible. =)
--
Joseph Carter <kngh...@bluecherry.net> Hey, that's MY freak show!
<Knghtbrd> mariab - don't think Debian hasn't had some very stupid and
obvious bugs before
<Knghtbrd> of course, we usually fix ours BEFORE we release =D
Henrique de Moraes Holschuh
> > update-rc.d isn't generic, but that has nothing to do with being diverted or
> > not...
>
> Er, you conveniently cut the part where you state:
*I* didn't say anything of the sort, ever. Check your headers. I know
file-rc, sysvinit and all the interfaces that deal with it fairly well,
since I had to to come up with invoke-rc.d. I would never call update-rc.d
generic.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Joerg Schilling
>WHY does the LSB even _define_ numeric UID settings? For every distrib I've
>used, Slackware, SuSe, Mandrake, Red Hat, Debian, Peanut, Stampede, and
>others, any system user (meaning system related such as bin, adm, wheel, ect
>ect) were always extrememly low UID numbers. This in turn signifies to the
>system, as stated in the POSIX standard (don't shoot me if I'm wrong, been a
>LONG time since I've read it), are reserved specificly for system related
>accounts. These accounts have the required access privileges set up before
>any distrib is relased, regardless of maker. So, if X for instances, needs
>access to the video hardware (using sys or some other system defined
>account) all one needs to do is set the permissions to that user.
Let me do a second try...
If you believe that there is no need to garantee people to NFS mount /usr
or anything that comes SUID/SGID to one of the system accounts, you don't need
to specify numeric id's for anything than root.
However, not specifying the numeric ID for "nobody" will introduce a big
potential security problem when old (outdated) program implementations like gnutar
or pax try to unpack TAR archives that conform to POSIX-2001 and hold users with
numeric IDs > 2097151 whily unpacking based on numeric IDs (e.g. because
the the passwd file is missing the right entries).
Jörg
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
Adam Lazur
> *I* didn't say anything of the sort, ever. Check your headers. I know
> file-rc, sysvinit and all the interfaces that deal with it fairly well,
> since I had to to come up with invoke-rc.d. I would never call update-rc.d
> generic.
Doh, my fault. I mentally merged your post and Martijn van Oosterhout's
as if they were by the same person.
--
Adam Lazur, Cluster Monkey
Trond Eivind Glomsrød
> On Wed, Feb 20, 2002 at 02:31:20PM -0500, Trond Eivind Glomsrød wrote:
> > They don't care about running on Debian - at least, they shouldn't.
>
> You're confused.
>
> ISV's using the LSB obviously care about running on Debian: they care about
> running on as many platforms as possible to increase their potential market
> share, either so they can make more money, or so they can be more
> famous.
My point it they shouldn't have to care about distribution specific
items, issues coming from Debian or anyone else. One of the main goals
of LSB is to isolate the developers from this.
> What they don't want to do is have to special case us. If they follow
> the LSB 1.0 or 1.1 specs, and make any use of the bin=uid 1 clause, then
> they'll find they *will* have to special case us, and that will annoy
> them, since the LSB's raison d'etre is to avoid that nonsense. Correcting
> the spec allows us to avoid annoying them. Not correcting it buys no
> one anything.
It's not a bug, it's a "why the ???? did this feature get added?"
issue, which also highlights the necessity of documenting _why_ things
are put into the standard. A specific release of particular
distribution not conforming to the LSB standard is not an LSB bug.
> > If they have written a program using this part of LSB 1.0, it
> > shouldn't matter if it's Debian, Slackware or Caldera they are
> > running on if these distribution claim to implement the
> > standard. If they don't claim to implement it, the program isn't
> > expected to run anyway.
>
> We're not designing this spec in a vacuum. There are real people out there
> with real needs that we're trying to satisfy. If we're not satisfying
> their needs now, we need to change it so we are. Debian is one set of
> such people, ISVs who want their products to run on both Red Hat and
> Debian are another.
Debian not complying with LSB is not much of LSB need, it's a Debian
need if they want to comply.
> Our aim is to let people say "Sure, my program will run on Linux. Doesn't
> matter what flavour. Red Hat, SuSE, Debian, Slackware, heck, even BSD
> or Solaris via the compatability layers." We're not aiming to have
> people say "It'll run on Red Hat and SuSE. It won't run on Debian,
> because although that's Linux, it's not *really* Linux". Or at least,
> the people who I've talked to aren't.
Then Debian could fix it if they want to comply with the standard.
> > Any revision of the standard shouldn't go through overnight, but
> > be in a future revision after being carefully reviewed, and a
> > rationale for the change should be given (as it should have for
> > being in there in the first place).
>
> Sure. All of these things should happen. But they shouldn't be used as an
> excuse to delay or block a necessary change for months (like has already
> happened on this very issue) when the *original spec* had absolutely
> none of these things.
Changes should not get silently and quickly put in, unless they're
typos or similar.
> > > We could do this tomorrow, and _no one_ would have any cause to
> > > complain. Anyone using it (developers, book printers, etc)
> > > would have cause.
>
> All those masses of developers shipping LSB 1.0 or 1.1 compliant software?
> Or the masses of publishers who've already written whole chapters about
> why uid 1 should be the bin user, even though we can't think of even a
> sentence to justify it?
Or just printing the standard? One thing is having a 1.0.1 with this
removed, but you don't just silently revise a standard. If I pick it
up in print, I want 1.0 to be 1.0. Not one of a couple of 1.0s.
> > Trond Eivind Glomsrød
> > Red Hat, Inc.
>
> Of course, I suppose Red Hat does have a market incentive to make it
> as difficult as possible for Debian to comply with the LSB.
>
> "Oh, no, your products won't run on Debian, because those hacker wannabes
> can't manage to comply with simple community developed standards. Better
> buy Red Hat instead."
>
> So I suppose someone does have a cause to complain afterall. My mistake.
That's just stupid.
> Cheers,
> aj, who'd be much less bitter if the last seven months had resulted in
> pretty much anything other than "Oh, but Debian should suffer for
> our art too, coz Red Hat did" (Hi, Chris)
Minimal suffering for everyone is a good thing.
Chris Lawrence
> provides init, then another init system could easily plug in by
> providing the lsb interface and _not_ the update-rc.d interface. (yes,
> this would require removing update-rc.d from policy and making the
> official way of adding an removing a bootup script to be the LSB way)
>
> If you're not getting what I'm hinting at, I'd like to move away from
> crappy SysV init and use something better in the future.
Then the lsb package would have to be updated to comply with the new
policy anyway, and conflict with versions of file-rc and sysvinit that
did not comply with the new policy.
> The LSB defining a sane way of genericizing init script installation and
> removal without adding SysV inspired braindamage is a glimmer of hope
> that one day I'll be able to use the NetBSD rc.d system [1] or Linux
> boot scripts [2] with Debian, both of which suck substantially less than
> SysV init.
Great, propose a policy change for woody+1, and if implemented then
the lsb package will support it, per policy.
> > My gut feeling is that init-functions *itself* should stay in the lsb
> > package, because it has to conform with LSB practice. I really don't
> > think it's a good idea for $random_debian_package to use the LSB
> > interface, as it's pretty lame compared to start-stop-daemon.
>
> I guess our views differ there.
>
> IMO it's pretty lame that everybody rolls their own init script and adds
> their own personal bugs when simple things like starting and stopping a
> daemon could be centralized (like the LSB does). IMO it's also pretty
> lame that any maintainer can spew data to the bootup screen in any way
> they see fit.
LSB does no such thing. The start_daemon and killproc functions only
do a fraction of what /sbin/start-stop-daemon do. The only way LSB is
better is that instead of using echo, it uses three functions for
success, warning, and failure.
> For example, RedHat has this sort of abstraction in their init scripts.
> This allowed Sun to easily override those functions with ones that
> display the startup status on the LCD of a cobalt box. This currently is
> pretty near impossible to do on a Debian system, but it really shouldn't
> be.
RH has higher-level abstraction than this. Even there, "echo" is
still used in their init scripts. For example, let me share the init
scripts for anacron on RH and Debian:
*** RH:
#!/bin/sh
# Startup script for anacron
#
# chkconfig: 2345 95 05
# description: Run cron jobs that were left out due to downtime
# Source function library.
. /etc/rc.d/init.d/functions
[ -f /usr/sbin/anacron ] || exit 0
prog="anacron"
start() {
echo -n $"Starting $prog: "
daemon anacron
RETVAL=$?
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/anacron
echo
return $RETVAL
}
stop() {
if test "x`pidof anacron`" != x; then
echo -n $"Stopping $prog: "
killproc anacron
echo
fi
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/anacron
return $RETVAL
}
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status anacron
;;
restart)
stop
start
;;
condrestart)
if test "x`pidof anacron`" != x; then
stop
start
fi
;;
*)
echo $"Usage: $0 {start|stop|restart|condrestart|status}"
exit 1
esac
exit 0
*** Debian:
#! /bin/sh
# /etc/init.d/anacron: start anacron
#
PATH=/bin:/usr/bin:/sbin:/usr/sbin
test -f /usr/sbin/anacron || exit 0
case "$1" in
start)
# Really on_ac_power is not a sufficient test, as it only looks at
# APM and we ought to also check whether we're on a UPS battery.
if test \! -x /usr/bin/on_ac_power || on_ac_power >/dev/null
then
echo -n "Starting anac(h)ronistic cron: anacron"
anacron -s
echo "."
else
echo "Starting anac(h)ronistic cron: deferred while on battery
power."
fi
;;
restart|force-reload|stop)
# nothing to do
:
;;
*)
echo "Usage: /etc/init.d/anacron start"
exit 1
;;
esac
exit 0
***
Frankly, I don't see anything more abstract in the Red Hat script than
the ability to localize the messages and the fact that start and stop
are separated out into functions. RH also sources a standard file at
the beginning, which could be used to redefine echo. That's the
extent to which things are abstracted.
LSB doesn't even abstract things that much...
Again, my position is that Debian-wide init functions should be
provided in a Debian core package, or by each init program. Anything
in /usr/lib/lsb, however, should be provided by the lsb package, but
should make use of facilities provided by Debian (including any future
upgrades to the init functionality). That way, you don't have any LSB
cruft on your system unless you want to install lsb-* packages.
Chris
--
Chris Lawrence <cnla...@olemiss.edu> - http://www.lordsutch.com/chris/
Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi
208 Deupree Hall - 662-915-5765
Adam Heath
> #!/bin/sh
> ...
> echo -n $"Starting $prog: "
Ew. This won't work in ash.
George Kraft IV
section and its maintenance. :-) In December of 1999 I took the action item
to investigate users & groups APIs, commands, user names, group names, uids, &
gids.
http://lists.debian.org/lsb-spec/2000/lsb-spec-200001/msg00056.html
From that list we sorted out what was to be standardized and what was to be left
out. The LSB's ABI and command tables were updated accordingly, then the rest
was discussed at workgroup & telephone conference meetings, and via email.
We should all agree that root=0, and systems require the "bin" and "daemon"
mnemonic user and group names. In retrospect, I guess if few programs/services
are hardcoding 1, then they are wrong and specifying bin or daemon equal to 1
would be worse. :-)
I agree that our processes need to be more systematic and/or precise. We will
fix this ASAP and run "bin=1" and tty(1) through the process.
http://www.linuxbase.org/spec/gLSB/gLSB/usernames.html
http://www.linuxbase.org/spec/gLSB/gLSB/tty.html
I appreciate everyone's constructive participation.
Sincerely,
George Kraft IV
g...@austin.ibm.com
Senior Software Engineer
IBM Linux Technology Center
Chair of the LSB
Wichert Akkerman
> We should all agree that root=0, and systems require the "bin" and "daemon"
> mnemonic user and group names.
I would still like to see a rationale for requiring bin and daemon, they
do not seem to serve any purpose.
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Michael Stone
> http://lists.debian.org/lsb-spec/2000/lsb-spec-200001/msg00056.html
>
> From that list we sorted out what was to be standardized and what was to be left
> out. The LSB's ABI and command tables were updated accordingly, then the rest
> was discussed at workgroup & telephone conference meetings, and via email.
So this debacle was caused by bad data? (bin and daemon are reversed
for, at least, D5)
> We should all agree that root=0, and systems require the "bin" and "daemon"
> mnemonic user and group names
Why? (not the root part ;-)
--
Mike Stone
George Kraft IV
>
> Previously George Kraft IV wrote:
> > We should all agree that root=0, and systems require the "bin" and "daemon"
> > mnemonic user and group names.
>
> I would still like to see a rationale for requiring bin and daemon, they
> do not seem to serve any purpose.
>
The thought was that some applications (and/or shell scripts) could/would fail
if root.root, bin.bin, and daemon.daemon did not exist on a system; however, the
other user and group names in the optional table below are just suggested.
http://www.linuxbase.org/spec/gLSB/gLSB/usernames.html
In short, the LSB v1.1.0 specification requires:
root.root = 0
bin.bin = 1
daemon.daemon
However, we've had a long discussion regarding bin = 1, and we will address
that. :-)
George (gk4)
Wichert Akkerman
> The thought was that some applications (and/or shell scripts)
> could/would fail if root.root, bin.bin, and daemon.daemon did not
> exist on a system
That doesn't answer my question though. There is no (documented or
otherwise) reason for bin and daemon existing. Nobody seems to know
what to use them for and I haven't ever seen anything that uses them.
Leaving them in LSB can only lead to different possibly conflicting
kinds of usage for those accounts which does not help at all.
The thought that an application might break also wasn't valid: applications
can break due to any difference between LSB and existing systems,
so if you follow that argument the LSB would have to document every
possible existing Linux system or an application just might break.
If an application does need an account for a special reason it can
always create a system account for itself and use that.
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Francesco P. Lovergine
> Previously George Kraft IV wrote:
> > The thought was that some applications (and/or shell scripts)
> > could/would fail if root.root, bin.bin, and daemon.daemon did not
> > exist on a system
>
> That doesn't answer my question though. There is no (documented or
> otherwise) reason for bin and daemon existing. Nobody seems to know
> what to use them for and I haven't ever seen anything that uses them.
>
> Leaving them in LSB can only lead to different possibly conflicting
> kinds of usage for those accounts which does not help at all.
>
> The thought that an application might break also wasn't valid: applications
> can break due to any difference between LSB and existing systems,
> so if you follow that argument the LSB would have to document every
> possible existing Linux system or an application just might break.
>
> If an application does need an account for a special reason it can
> always create a system account for itself and use that.
>
> Wichert.
>
Completely agree. Those accounts exist for hystorical reasons in
other unices. I see no real rationale to require their existence
in debian nowdays.
--
Francesco P. Lovergine
Martijn van Oosterhout
> > The thought was that some applications (and/or shell scripts)
> > could/would fail if root.root, bin.bin, and daemon.daemon did not
> > exist on a system
>
> That doesn't answer my question though. There is no (documented or
> otherwise) reason for bin and daemon existing. Nobody seems to know
> what to use them for and I haven't ever seen anything that uses them.
Actually, on my debian unstable system here:
daemon 111 0.0 0.3 1416 464 ? S 08:21 0:00 /sbin/portmap
daemon 290 0.0 0.4 1420 608 ? S 08:21 0:00 /usr/sbin/atd
So they are used and we can't summarily remove them. These could be shunted
to another user, but which one? They *are* daemons.
--
Martijn van Oosterhout <kle...@svana.org>
http://svana.org/kleptog/
> If the company that invents a cure for AIDS is expected to make their
> money back in 17 years, why can't we ask the same of the company that
> markets big-titted lip-syncing chicks and goddamn cartoon mice?
Wichert Akkerman
> Actually, on my debian unstable system here:
>
> daemon 111 0.0 0.3 1416 464 ? S 08:21 0:00 /sbin/portmap
> daemon 290 0.0 0.4 1420 608 ? S 08:21 0:00 /usr/sbin/atd
That's a bug, they should create their own user and use that instead.
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Chris Lawrence
available at:
http://people.debian.org/~lawrencc/
Matt Taggart and I had an off-list discussion about what should be in
the package, and this is the culmination of that work.
Again, we'd like to see an LSB package that uses the init
functionality so we can test our implementation. (The apache package
*could*, but the prerm and postinst scripts appear to be Red Hat
scripts with all the actions commented out.)
Chris
--
Chris Lawrence <lawr...@debian.org> - http://www.lordsutch.com/chris/
Joey Hess
> FYI: I have a release candidate of the lsb package (version 1.1.0-3)
> available at:
>
> http://people.debian.org/~lawrencc/
This package contains a number of directories that are already in
base-files. In particular, all the /opt crap. base-files already
includes all that, at least it makes them on new installs. It does not
force you to have them, and if you rmdir them it won't put them back.
Do we need to worry about upgraded-from-potato debian systems that do not
contain /opt and /etc/opt, and lsb packages that rely on these directories
to exist? If people are installing lsb packages by converting them with
alien, the resulting debs will include /opt if the package has files in
/opt and it won't matter whether the system they are installed on has already
been forced to have a /opt already or not. Same with /etc/opt. The only
failure I can envision would be a package that did not include files in
one of these two directories but tried to symlink or copy stuff into them
by hand, if they did not exist.
You cannot just include /usr/local/games in a package; that is a clear
violation of policy. Installing of this package will fail on systems
where /usr/local is not mounted writable.
Since `/usr/local' can be mounted read-only from a remote server,
these directories must be created and removed by the `postinst' and
`prerm' maintainer scripts and not be included in the `.deb' archive.
These scripts must not fail if either of these operations fail.
Anyway, base-files creates /usr/local/games at the same time it creates the
rest of /usr/local.
(I also don't understand why it contains a /lib directory, but that is
minor.)
The note about how to install lsb apps on debian should perhaps be a bit
closer to the top of the file.
--
see shy jo
Joey Hess
file and the bsd copyrights on the init-functions.
--
see shy jo
Chris Lawrence
detection" on, so I'll err on the side of caution... :)]
On Feb 25, Joey Hess wrote:
> Chris Lawrence wrote:
> > FYI: I have a release candidate of the lsb package (version 1.1.0-3)
> > available at:
> >
> > http://people.debian.org/~lawrencc/
>
> This package contains a number of directories that are already in
> base-files. In particular, all the /opt crap. base-files already
> includes all that, at least it makes them on new installs. It does not
> force you to have them, and if you rmdir them it won't put them
> back.
[good points snipped]
> You cannot just include /usr/local/games in a package; that is a clear
> violation of policy. Installing of this package will fail on systems
> where /usr/local is not mounted writable.
>
> Since `/usr/local' can be mounted read-only from a remote server,
> these directories must be created and removed by the `postinst' and
> `prerm' maintainer scripts and not be included in the `.deb' archive.
> These scripts must not fail if either of these operations fail.
>
> Anyway, base-files creates /usr/local/games at the same time it creates the
> rest of /usr/local.
Ah... I see they're created in the postinst of base-files. I'll
remove the offending directories.
> (I also don't understand why it contains a /lib directory, but that is
> minor.)
There's a symlink that's installed in /lib by the package, hence why
/lib is included. For some reason, it's the last thing in the tar
file in the archive.
> The note about how to install lsb apps on debian should perhaps be a bit
> closer to the top of the file.
Probably. I'll rearrange and put together a -4 release.
Chris
--
Chris Lawrence <lawr...@debian.org> - http://www.lordsutch.com/chris/
Wichert Akkerman
> There's a symlink that's installed in /lib by the package, hence why
> /lib is included. For some reason, it's the last thing in the tar
> file in the archive.
dpkg sorts symlinks the the end in a deb on purpose to prevent having
dangling symlinks installed on the system at any point in time.
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Josip Rodin
> [Not sure if you want a CC or not. I don't have "magic header
> detection" on, so I'll err on the side of caution... :)]
His mail had:
Mail-Followup-To: debian...@lists.debian.org,
Chris Lawrence <lawr...@debian.org>
So, I'm fairly sure he didn't want a copy.
--
2. That which causes joy or happiness.
Steve Langasek
> Chris Lawrence wrote:
> > FYI: I have a release candidate of the lsb package (version 1.1.0-3)
> > available at:
> > http://people.debian.org/~lawrencc/
> This package contains a number of directories that are already in
> base-files. In particular, all the /opt crap. base-files already
> includes all that, at least it makes them on new installs. It does not
> force you to have them, and if you rmdir them it won't put them back.
> Do we need to worry about upgraded-from-potato debian systems that do not
> contain /opt and /etc/opt, and lsb packages that rely on these directories
> to exist? If people are installing lsb packages by converting them with
> alien, the resulting debs will include /opt if the package has files in
> /opt and it won't matter whether the system they are installed on has already
> been forced to have a /opt already or not. Same with /etc/opt. The only
> failure I can envision would be a package that did not include files in
> one of these two directories but tried to symlink or copy stuff into them
> by hand, if they did not exist.
Hmm, but one of our two primary recommended methods of handling
configuration files in native packages is by copying the files to /etc
in the postinst. If /etc/opt is not guaranteed to be installed by
default, then any lsb packages would be unable to take advantage of this
approach.
Steve Langasek
postmodern programmer
Adam Heath
> Previously Chris Lawrence wrote:
> > There's a symlink that's installed in /lib by the package, hence why
> > /lib is included. For some reason, it's the last thing in the tar
> > file in the archive.
>
> dpkg sorts symlinks the the end in a deb on purpose to prevent having
> dangling symlinks installed on the system at any point in time.
Which reminds me, I need to add that symlink-reorder-on-extract patch to HEAD.
Adam Heath
> The either ship the dir in the package, or have something like
>
> [ -d /etc/opt ] || mkdir -p /etc/opt
Just mkdir -p /etc/opt is fine.
Steve Langasek
> * Steve Langasek
> | Hmm, but one of our two primary recommended methods of handling
> | configuration files in native packages is by copying the files to /etc
> | in the postinst. If /etc/opt is not guaranteed to be installed by
> | default, then any lsb packages would be unable to take advantage of this
> | approach.
> The either ship the dir in the package, or have something like
> [ -d /etc/opt ] || mkdir -p /etc/opt
> in the postinst
Is Debian any longer LSB-compliant if we require LSB packages to provide
this directory themselves? If someone has gone to the trouble of
installing the lsb .deb on Debian, they should get a complete
LSB-compliant system; and any admin that gets irritated that /etc/opt
shows up again when they apt-get install lsb should learn to cope,
because that's part of what they're *asking* for by typing that command.
Steve Langasek
postmodern programmer
Joseph Carter
> > The either ship the dir in the package, or have something like
> >
> > [ -d /etc/opt ] || mkdir -p /etc/opt
>
> Just mkdir -p /etc/opt is fine.
install -d -m 755 /etc/opt might be a better suggestion if only because I
have seen more than one script accompanying a piece of software didn't
save/change umask properly before doing that kind of thing. I'm not sure
if I've ever seen that in a Debian package script or not, but better safe
than sorry. =p
--
Joseph Carter <kngh...@bluecherry.net> The guy with a rocket launcher
<knghtbrd> *sigh* My todo list is like the fucking energizer bunny
<knghtbrd> It keeps growing and growing and growing and ...
Matt Wilson
our functionality as well.
Cheers,
Matt
On Sun, Feb 24, 2002 at 10:22:00PM -0600, Chris Lawrence wrote:
> FYI: I have a release candidate of the lsb package (version 1.1.0-3)
> available at:
>
> http://people.debian.org/~lawrencc/
>
> Matt Taggart and I had an off-list discussion about what should be in
> the package, and this is the culmination of that work.
>
> Again, we'd like to see an LSB package that uses the init
> functionality so we can test our implementation. (The apache package
> *could*, but the prerm and postinst scripts appear to be Red Hat
> scripts with all the actions commented out.)
>
>
> Chris
> --
> Chris Lawrence <lawr...@debian.org> - http://www.lordsutch.com/chris/
>
>
> --
> To UNSUBSCRIBE, email to lsb-spec...@lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listm...@lists.linuxbase.org
Wichmann, Mats D
> Ditto, we need some LSB package that installs an init script to test
> our functionality as well.
Suggest some existing packages that do so and I can take a little
bit of time to root around and see if they're compilable as LSB
apps.
Mats
Matt Wilson
On Tue, Feb 26, 2002 at 09:51:03AM -0800, Wichmann, Mats D wrote:
>
> Suggest some existing packages that do so and I can take a little
> bit of time to root around and see if they're compilable as LSB
> apps.
Wichmann, Mats D
avoiding the init-script issue?
Matt Wilson
> Apache's already in the app battery. Does that mean it got built
> avoiding the init-script issue?
Or ignoring it.
Cheers,
Matt
M. Drew Streib
> Apache's already in the app battery. Does that mean it got built
> avoiding the init-script issue?
Yes. I didn't have any implementations to work against, so I
skipped/avoided it at the time of the build. The source rpm is also
on the ftp site, so it should be relatively easy to modify...
-drew
--
M. Drew Streib <dt...@dtype.org>, Free Standards Group (freestandards.org)
co-founder, SourceForge.net | core team, freedb | sysadmin, Linux Intl.
creator, keyanalyze report | maintnr, *.us.pgp.net | other freedom/law
Matt Taggart
Stuart Anderson writes...
> On Wed, 20 Feb 2002, Andrew Pimlott wrote:
>
> > I guess this will come off as smart, but if it is "controlled", I
> > would have expected someone to write down why this section was
> > written in the first place.
>
> Good point. In fact, how to maintain a rational as part of the document
> was discussed. At the time, it didn't seem critical to include the rational
> in the standards document. (You can have a good debate about wether rational
> is appropriate for the normative parts of a standards).
I agreee. While the FHS has done a good job including rationale in their spec,
I think the rationale for the LSB will be much longer and warants a separate
document.
> Anyway, because we
> all learn from what we do, it now seems that having the rational would be
> helpful.
So where should the rationale live? Can this document be created now and
people record what they remember so it's not lost forever?
> > It sounds like the early versions were hastily slapped together
> > (this is not the only section that gives me this impression),
>
> There were fewer people contributing back then, so some section probably were
> hastily written.
I have added a "rationale" requirement to the (in development) lsb-futures
"Selection Criteria" document,
http://www.linuxbase.org/futures/criteria/index.html#rationale
So all new additions to the LSB will be required to document their rationale
before being recommended for addition to the LSB.
> It doesn't have to be a painful process. I didn't mean to imply that it shoul
> be, or even that is has to be a heavy process, only that some process must
> be followed. Changing the document simply because write access is available
> is not an appropriate process.
>
> I think we've demonstrated that there is concensus that the change should be
> made. I agree with that.
>
> I do think that before removing or deprecating something we should make sure
> we understand why it was added in the first place. If the answer is that it
> was rushed and overlooked in the beginning, then that's fine. If there is som
> other reason, then we need to be sure that we have considered it.
>
> Once this is done, then we can change the wording in the spec to indicate tha
> is is deprecated.
How will this be done, by editing the spec or issuing some sort of errata
document?
Is this particular issue (UID of "bin" and "daemon") now understood enough to
make these changes? Can we stop testing for it and not require it for
certification? This is holding up Debian compliance and certification.
Thanks,
--
Matt Taggart Linux Development Lab
tag...@fc.hp.com HP Linux Systems Operation
George Kraft IV
> make these changes? Can we stop testing for it and not require it for
> certification? This is holding up Debian compliance and certification.
We have concluded that "daemon" is not required on Debian if atd's use of
"daemon" gets fixed; however, what about the other distributions?
Also, changing bin=1 not to be required is a *strong* recommendation. It would
be nice if someone could do a getpwnam and getuid search to look for code that
requires bin=1. However, I would like to avoid changing the spec in absence of
a rationale unless someone provides a proof by induction.
We can change the spec where it makes sense, but for the right reason, not just
the sweaky wheel. :-)
We will submit these as bugs, then review them with a more structured process.
George (gk4)
Steve Langasek
> > Is this particular issue (UID of "bin" and "daemon") now understood enough to
> > make these changes? Can we stop testing for it and not require it for
> > certification? This is holding up Debian compliance and certification.
> We have concluded that "daemon" is not required on Debian if atd's use of
> "daemon" gets fixed; however, what about the other distributions?
Why should the fact that some distributions use "daemon" for their own
software lead to this restriction being imposed on other distributions?
The LSB is about documenting a set of features that third-party vendors
can and should depend on being present in all Linux distributions. It
should NOT be a means of imposing arbitrary requirements on Linux
distributions when these requirements are of no real value to software
vendors.
> Also, changing bin=1 not to be required is a *strong* recommendation. It would
> be nice if someone could do a getpwnam and getuid search to look for code that
> requires bin=1. However, I would like to avoid changing the spec in absence of
> a rationale unless someone provides a proof by induction.
It hampers the usefulness of the spec, because fewer distros are in
compliance than could be if this requirement were not present; and no
one has yet come up with a solid reason why it should be in the spec at
all. What more proof is necessary? If the simple fact that the spec
includes artificial obstacles to compliance does not persuade you that
it needs to be changed, what will?
Steve Langasek
postmodern programmer
Ron Tidd
> The LSB is about documenting a set of features that third-party vendors
> can and should depend on being present in all Linux distributions. It
> should NOT be a means of imposing arbitrary requirements on Linux
> distributions when these requirements are of no real value to software
> vendors.
This makes sense to me.
Look at the big picture as it applies to the goals to the LSB. Does the
specification of standard users fall within the scope of the LSB?
Yes?
Given that, ask the question "Are the users daemon or bin required for
the "standard" base install?"
Not requiring the users bin or daemon (or their associated uid's) in the
spec will not disallow their use if I am reading the documentation
correctly.
However, should they be mandated for all LSB compliant distributions?
Even if you can't come up with a firm example that indicates their
inclusion in the standard is more important than requiring an isolated
program (or two) to be modified to comply with the LSB?
--Ron--