Oldies Online Casino - Happy New Year!!!

From Oldies@murphy.debian.org Tue Jan 2 08:20:05 2001 From: Oldies@murphy.debian.org (Oldies@murphy.debian.org) Date: Tue, 02 Jan 2001 02:20:05 -0600 Subject: 01-01-2001 Message-ID: <36893.097280659720100.291204@localhost> Oldies Online Casino - Happy New Year!!!

Oldies Online Casino
Would like to welcome you and your family a Happy New Year!

We Would also like to offer ALL NEW & EXISTING Members a
Holiday 25% Bonus
Oldies Online Casino offers Free no download Flash Internet
gambling, games include craps, keno, slots, video poker,
roulette and blackjack in real time. Play for fun or cash!
http://www.oldiesonlinecasino.com

to unsubscribe click here

From johannes@caldera.de Thu Jan 4 12:40:04 2001 From: johannes@caldera.de (Johannes Poehlmann) Date: Thu, 4 Jan 2001 13:40:04 +0100 Subject: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions Message-ID: <20010104134004.A28627@caldera.de> This proposal is also checked in into George Krafts Comment submission form Problem: LSB says nothing about File Permissions. o This makes it possible to set up an LSB-conforming package and a LSB conforming Linux system where the application can not run on the linux system. o LSB-conforming systems should be allowed to use very restrictive permission schemes, not to make security and LSB a contradiction. Consequences: o LSB conforming applications should run with very restrictive file permissions o LSB-conforming systems should not be required to give much file permissions. Proposal: In this proposal "System" means a "LSB compliant system" and "application" means a "LSB compliant application". I. Write Permissions 1. Directories o The application must not depend on having directory write permission outside /tmp, /var/tmp and his home directory. o The application must not depend on owning these directories. o The system may restrict directory write permissions for these directories by setting the "sticky bit" for them. ( To prevent the application to remove "foreign" files, e.g. a empty .rhosts file owned by root.) 2. Files The application must not depend on file write permission on files not owned by the user it runs under with the exeption of its personal inbox /var/mail/ II. Read Permissions and Execute Permissions o The application must not depend on having read permission to every file and directory. o The system must grant the permissions needed to use them to all libraries, executables and data files mentioned in the LSB document, and included standards. III. Suid and Sgid Permissions The application must not depend on suid/sgid permissions on a file. Instead, the system is responsible that all system commands are just doing their job right and have the permissions needed. Rationale: Let us make security officers happy. Lets give them the freedom to take sgid/suid perms away, as long as they do not break the systems funtionality. IV. Removable Media (Cdrom, Floppy,...) o LSB systems may use mount options "noauto", "nouser", "nosuid" and "nodev" for removeable media. Also "uid=X", "gid=X" may be used with a non-zero uid/gid value X. Rationale: allow running applications from removable media, but allow system to prevent application from bad behaviour. V. Run-from-removable media applications o They must not depend on logging in as user root. VI.Installable applications (This paragraph should possibly be part of Chapter VII. - Package Format and Installation) These must not depend on BOTH to o log in as user root o run a self-supplied binary install routine Rationale: Let us make security officers less unhappy. -- ______ ___ / ___/__/ / Caldera (Deutschland) GmbH / /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany /_____/_/ /____/ software developer / lsb project ==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399 ----- End forwarded message ----- -- ______ ___ / ___/__/ / Caldera (Deutschland) GmbH / /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany /_____/_/ /____/ software developer / lsb project ==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399 ----- End forwarded message ----- -- ______ ___ / ___/__/ / Caldera (Deutschland) GmbH / /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany /_____/_/ /____/ software developer / lsb project ==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399 From alan@lxorguk.ukuu.org.uk Thu Jan 4 15:02:10 2001 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Thu, 4 Jan 2001 15:02:10 +0000 (GMT) Subject: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions In-Reply-To: <20010104134004.A28627@caldera.de> from "Johannes Poehlmann" at Jan 04, 2001 01:40:04 PM Message-ID: > I. Write Permissions > > 1. Directories > > o The application must not depend on having directory write > permission outside /tmp, /var/tmp and his home directory. s/his/its/ (language pedantry, not intended as a criticism) > o The application must not depend on owning these directories. > o The system may restrict directory write permissions for these > directories by setting the "sticky bit" for them. Including home ? > ( To prevent the application to remove "foreign" files, > e.g. a empty .rhosts file owned by root.) > o The system must grant the permissions needed to use them > to all libraries, executables and data files mentioned in the > LSB document, and included standards. Stop a moment. Grant to whom ? Do I grant perl the ability to the shadow password file for example ;) > o log in as user root 'root' isnt always the name used. There may be multiple priviledge levels - how about 'log in as a privileged user' (3 .sigs deleted - maintenance suggested 8)) Alan From johannes@caldera.de Thu Jan 4 17:42:33 2001 From: johannes@caldera.de (Johannes Poehlmann) Date: Thu, 4 Jan 2001 18:42:33 +0100 Subject: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Thu, Jan 04, 2001 at 03:02:10PM +0000 References: <20010104134004.A28627@caldera.de> Message-ID: <20010104184232.B8891@caldera.de> On Thu, Jan 04, 2001 at 03:02:10PM +0000, Alan Cox wrote: > > o The application must not depend on having directory write > > permission outside /tmp, /var/tmp and his home directory. > s/his/its/ > (language pedantry, not intended as a criticism) > ACK > > o The application must not depend on owning these directories. > > o The system may restrict directory write permissions for these > > directories by setting the "sticky bit" for them. > > Including home ? > Yes, as local sysadmin I want to be able to place a empty rhosts file (owned by root) in home directories, to prevent users from opening rsh security holes. To prevent the users from deleting .rhosts, I need the sticky bit on the home directory. > > o The system must grant the permissions needed to use them > > to all libraries, executables and data files mentioned in the > > LSB document, and included standards. > Stop a moment. Grant to whom ? Do I grant perl the ability to the shadow > password file for example ;) OK, let "reword" this paragraph. o The system must grant to the application the permissions needed to use all libraries, executables and data files mentioned in the LSB document and included standards. > > o log in as user root > > 'root' isnt always the name used. There may be multiple priviledge levels - > how about 'log in as a privileged user' ACK -- ______ ___ / ___/__/ / Caldera (Deutschland) GmbH / /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany /_____/_/ /____/ software developer / lsb project ==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399 From alan@lxorguk.ukuu.org.uk Thu Jan 4 17:50:14 2001 From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Thu, 4 Jan 2001 17:50:14 +0000 (GMT) Subject: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions In-Reply-To: <20010104184232.B8891@caldera.de> from "Johannes Poehlmann" at Jan 04, 2001 06:42:33 PM Message-ID: > > > o The system must grant the permissions needed to use them > > > to all libraries, executables and data files mentioned in the > > > LSB document, and included standards. > > > Stop a moment. Grant to whom ? Do I grant perl the ability to the shadow > > password file for example ;) > OK, let "reword" this paragraph. > > o The system must grant to the application the permissions needed > to use all libraries, executables and data files mentioned in the > LSB document and included standards. That still says I have to give it /etc/shadow ;) Perhaps we need to define public/private files ? From gk4@us.ibm.com Thu Jan 4 18:46:33 2001 From: gk4@us.ibm.com (George Kraft) Date: Thu, 4 Jan 2001 12:46:33 -0600 Subject: REVIEW for the newly posted LSB 0.4 Message-ID: The newly posted LSB 0.4 is taking comments until Wednesday January 24th, 2001. http://www.linuxbase.org/spec/lsbreview.html The LSB workgroup will review comments on Tuesday January 30th, 2001 in New York city. Please RSVP, then read the agenda and prepare in advance. http://www.linuxbase.org/talks/20010130.html Your input and participation in the online review and workgroup meeting is welcomed. George Kraft IV gk4@us.ibm.com From johannes@caldera.de Fri Jan 5 12:32:34 2001 From: johannes@caldera.de (Johannes Poehlmann) Date: Fri, 5 Jan 2001 13:32:34 +0100 Subject: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Thu, Jan 04, 2001 at 05:50:14PM +0000 References: <20010104184232.B8891@caldera.de> Message-ID: <20010105133234.A11612@caldera.de> I hope we can fix it that way: o The system must grant to the application the permissions needed to use all system interfaces (ABIs) mentioned in the LSB document and included standards. Lets test this with Alans examle: Chapter 15.1 (User Database) does not mention the shadow password file. There is the sentence: The passwd(5) user database should only be read and updated form the following APIs: .... This explicitly makes passwd a "non interface". By not even mentioning it, the shadow file is made a "non interface" too, implicitly. On Thu, Jan 04, 2001 at 05:50:14PM +0000, Alan Cox wrote: > > > > o The system must grant the permissions needed to use them > > > > to all libraries, executables and data files mentioned in the > > > > LSB document, and included standards. > > > Stop a moment. Grant to whom ? Do I grant perl the ability to the shadow > > > password file for example ;) > > OK, let "reword" this paragraph. > > > > o The system must grant to the application the permissions needed > > to use all libraries, executables and data files mentioned in the > > LSB document and included standards. > That still says I have to give it /etc/shadow ;) Perhaps we need to define > public/private files ? > -- > > To UNSUBSCRIBE, email to lsb-spec-request@lists.linuxbase.org > with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org -- ______ ___ / ___/__/ / Caldera (Deutschland) GmbH / /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany /_____/_/ /____/ software developer / lsb project ==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399 From tytso@mit.edu Mon Jan 8 23:55:14 2001 From: tytso@mit.edu (tytso@mit.edu) Date: Mon, 8 Jan 2001 18:55:14 -0500 Subject: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions In-Reply-To: <20010104134004.A28627@caldera.de> (message from Johannes Poehlmann on Thu, 4 Jan 2001 13:40:04 +0100) References: <20010104134004.A28627@caldera.de> Message-ID: <200101082355.f08NtEo10077@snap.thunk.org> Date: Thu, 4 Jan 2001 13:40:04 +0100 From: Johannes Poehlmann Problem: LSB says nothing about File Permissions. o This makes it possible to set up an LSB-conforming package and a LSB conforming Linux system where the application can not run on the linux system. o LSB-conforming systems should be allowed to use very restrictive permission schemes, not to make security and LSB a contradiction. I'm not sure we want to go here. Permissions generally are a system administrator issue much more than they are a distribution issue, and trying to word things so that we don't prohibit perfectly sane configurations might be very difficult. For example, there are probably certain system users (like the one used by the imap daemon, or the one used by the anonymous FTP daemon) who might have very restrictive permissions schemes. Is this allowed? I would argue that an LSB statement which prohibited this type of security precaution is broken, and we shouldn't go there. And even if we specify that "users" must be given such permissions, maybe in some cases there will some set of users that should be given very restrictive permissions. My suggest is that we not try to address this "problem". If a distribution sets such a highly restrictve set of permissions, the system administrator can always "fix" the permissions very easily, and if someone did try to sell such a super-secure distribution as a desktop, market forces will probably solve the problem very quickly. (And in a server environment, as a sysadmin I'd much rather have a system which was oversecured, and which I could open up exactly what is needed to allow applications to run, rather than a system which was shipped "insecure out of the box".) - Ted From venom@cibs9.sns.it Tue Jan 9 09:37:31 2001 From: venom@cibs9.sns.it (V man) Date: Tue, 9 Jan 2001 10:37:31 +0100 (CET) Subject: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions In-Reply-To: <200101082355.f08NtEo10077@snap.thunk.org> Message-ID: On Mon, 8 Jan 2001 tytso@mit.edu wrote: > Date: Mon, 8 Jan 2001 18:55:14 -0500 > From: tytso@mit.edu > To: johannes@caldera.de > Cc: lsb-spec@lists.linuxbase.org > Subject: Re: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir > permissions > Resent-Date: Tue, 9 Jan 2001 00:57:40 +0100 > Resent-From: lsb-spec@lists.linuxbase.org > > Date: Thu, 4 Jan 2001 13:40:04 +0100 > From: Johannes Poehlmann > > Problem: > > LSB says nothing about File Permissions. > > o This makes it possible to set up an LSB-conforming package > and a LSB conforming Linux system where the application can > not run on the linux system. > > o LSB-conforming systems should be allowed to use very restrictive > permission schemes, not to make security and LSB a contradiction. > > I'm not sure we want to go here. Permissions generally are a system > administrator issue much more than they are a distribution issue, and > trying to word things so that we don't prohibit perfectly sane > configurations might be very difficult. Exactly! i would say that we should recognize it, maybe saying that a kind of reasonable permission scheme is suggested (that is almost what we say shipping with most distributions), and the system manager is free to use a mutch more restrictive one as mutch as a less restrictive one. Luigi Genoni From quinlan@transmeta.com Thu Jan 11 22:14:32 2001 From: quinlan@transmeta.com (Daniel Quinlan) Date: Thu, 11 Jan 2001 14:14:32 -0800 Subject: lpr subset standard wanted Message-ID: <200101112214.OAA10262@magnesium.transmeta.com> If possible, I would like to document the subset of lpr functionality that can be safely used by applications into the LDPS 1.1 portability guidelines and perhaps the LSB specification as well. Could someone investigate: - CUPS - BSD lpr - GNU lpr - lprng and find out which options/features are supported by all of them (and then, which options/features have the same behavior). If you're interested in this task, please let me know. A draft would need to be completed in one week if this is to make the LDPS 1.1 beta. (The current target for LDPS 1.1 beta is January 25th.) - Dan From johannes@caldera.de Fri Jan 12 17:44:24 2001 From: johannes@caldera.de (Johannes Poehlmann) Date: Fri, 12 Jan 2001 18:44:24 +0100 Subject: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions In-Reply-To: <200101082355.f08NtEo10077@snap.thunk.org>; from tytso@mit.edu on Mon, Jan 08, 2001 at 06:55:14PM -0500 References: <20010104134004.A28627@caldera.de> <200101082355.f08NtEo10077@snap.thunk.org> Message-ID: <20010112184424.C14853@caldera.de> Is it possible to misunderstand my proposal as "bossing around" Distributions ? > LSB says nothing about File Permissions. > o This makes it possible to set up an LSB-conforming package > and a LSB conforming Linux system where the application can > not run on the linux system. I fear that future LSB-compliant distributions could be bashed to dead if say LSB-compliant oracle can not run on them because of permission conflicts. > o LSB-conforming systems should be allowed to use very restrictive > permission schemes, not to make security and LSB a contradiction. If we do not spec permissions at all, we will have a de facto standard which says: All major ISV packages have to run, so give them the permissions they need. This will force LSB compliant distributions to grant a lot of file/dir permissions. The proposal proper gives the Distro/Sysadmin the greatest possible freedom on the cost of ISVs: If we forbid ISVs to demand certain permissions the Distro/Admin has the FREEDOM to grant them or not. > I'm not sure we want to go here. Permissions generally are a system > administrator issue much more than they are a distribution issue, and > trying to word things so that we don't prohibit perfectly sane > configurations might be very difficult. For example, there are probably > certain system users (like the one used by the imap daemon, or the one > used by the anonymous FTP daemon) who might have very restrictive > permissions schemes. Is this allowed? I would argue that an LSB > statement which prohibited this type of security precaution is broken, > and we shouldn't go there. Ted, that is exactly the situation i want to prevent > My suggest is that we not try to address this "problem". If a > distribution sets such a highly restrictve set of permissions, the > system administrator can always "fix" the permissions very easily, and > if someone did try to sell such a super-secure distribution as a > desktop, market forces will probably solve the problem very quickly. Is this good ? Do we want future bad press for Linux and the LSB like: "Standard Linux is open to XYZ-attack" ? -- ______ ___ / ___/__/ / Caldera (Deutschland) GmbH / /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany /_____/_/ /____/ software developer / lsb project ==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399 From johannes@caldera.de Fri Jan 12 17:52:48 2001 From: johannes@caldera.de (Johannes Poehlmann) Date: Fri, 12 Jan 2001 18:52:48 +0100 Subject: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions In-Reply-To: ; from venom@cibs9.sns.it on Tue, Jan 09, 2001 at 10:37:31AM +0100 References: <200101082355.f08NtEo10077@snap.thunk.org> Message-ID: <20010112185247.D14853@caldera.de> On Tue, Jan 09, 2001 at 10:37:31AM +0100, V man wrote: > On Mon, 8 Jan 2001 tytso@mit.edu wrote: > > From: Johannes Poehlmann > > LSB says nothing about File Permissions. > > > > o This makes it possible to set up an LSB-conforming package > > and a LSB conforming Linux system where the application can > > not run on the linux system. > > > > I'm not sure we want to go here. Permissions generally are a system > > administrator issue much more than they are a distribution issue, and > > trying to word things so that we don't prohibit perfectly sane > > configurations might be very difficult. > Exactly! i would say that we should recognize it, maybe saying that > a kind of reasonable permission scheme is suggested (that is almost what > we say shipping with most distributions), and the system > manager is free > to use a mutch more restrictive one as mutch as a less restrictive one. Hi Luigi, We need to keep the Distributions/system managers freedom, to be as much restrictive or permissive he wants. To guarantee this, we must forbid Third Party Software Vendors ("ISVs") to demand more then a reasonable set of permissions. If we fail to do so, major ISV packages will demand arbitrary permissions and you as a Distributor had to grant them. If you do not, you will face bad press like: "Paranoia Linux claims to be LSB compliant but fails to execute LSB-compliant oracle/MSLinWord/Whatever". -- ______ ___ / ___/__/ / Caldera (Deutschland) GmbH / /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany /_____/_/ /____/ software developer / lsb project ==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399 From venom@DarkStar.sns.it Fri Jan 12 22:40:44 2001 From: venom@DarkStar.sns.it (V-man) Date: Fri, 12 Jan 2001 23:40:44 +0100 (CET) Subject: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions In-Reply-To: <20010112185247.D14853@caldera.de> Message-ID: On Fri, 12 Jan 2001, Johannes Poehlmann wrote: > On Tue, Jan 09, 2001 at 10:37:31AM +0100, V man wrote: > > > On Mon, 8 Jan 2001 tytso@mit.edu wrote: > > > > From: Johannes Poehlmann > > > > LSB says nothing about File Permissions. > > > > > > o This makes it possible to set up an LSB-conforming package > > > and a LSB conforming Linux system where the application can > > > not run on the linux system. > > > > > > I'm not sure we want to go here. Permissions generally are a system > > > administrator issue much more than they are a distribution issue, and > > > trying to word things so that we don't prohibit perfectly sane > > > configurations might be very difficult. > > Exactly! i would say that we should recognize it, maybe saying that > > a kind of reasonable permission scheme is suggested (that is almost what > > we say shipping with most distributions), and the system > > manager is free > > to use a mutch more restrictive one as mutch as a less restrictive one. > > Hi Luigi, > > We need to keep the Distributions/system managers freedom, to be as > much restrictive or permissive he wants. > > To guarantee this, we must forbid Third Party Software Vendors ("ISVs") > to demand more then a reasonable set of permissions. > > If we fail to do so, major ISV packages will demand arbitrary permissions > and you as a Distributor had to grant them. If you do not, you will face > bad press like: "Paranoia Linux claims to be LSB compliant but fails to > execute LSB-compliant oracle/MSLinWord/Whatever". > I understand this point, and you are right. This, for what i see, means that we need to keep a really good equilibrium. For what i know, the traditional set of permission we see in other older Unixes is not suitable, since it usually is too open, and it makes even difficoult for sysadmins to adopt a more restrictive set. So, we should identify clearly, for example, which file we consider that just the sysadmin should access, and then establish a set where there is no need for user application to access them, nor to use SUID bits to access them anyway (and also forbit SUID for every user). I know this is difficoult, but this should be the goal. For example i discovered oracle to use suid bits (as oracle user, of course), to do many things. Just immagine how many exploits. Think to those applications that have to be installed as root user! Bests Luigi Genoni From tkamppeter@mandrakesoft.com Sat Jan 13 20:02:20 2001 From: tkamppeter@mandrakesoft.com (Till Kamppeter) Date: Sat, 13 Jan 2001 21:02:20 +0100 Subject: [Fwd: lpr subset standard wanted] References: <3A5E3551.8BCF4B84@mandrakesoft.com> Message-ID: <3A60B44C.1A120B8B@mandrakesoft.com> This is a multi-part message in MIME format. --------------E7ECA23A21EA33ED14C1408D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CUPS (www.cups.org) ------------------- The command line commands (lpr, lpq, lprm, lpc, lp, cancel, ...) are made as compatible as possible to both the System V and the BSD version of LPD. The programs have also exactly the same names as the LPD commands, so that one does not need to change the defaults of the applications when one switches from LPD to CUPS. See the manual pages of the commands (attached, use "bunzip2 ; man ./" to read them). See also www.cups.org/documentation.html Note that some options (as e-mail notification in the end of the job) are not implemented. XPP (http://cups.sourceforge.net/xpp/) understands most of the lpr and some of the lp options. About QtCUPS (http://cups.sourceforge.net/qtcups/) I do not know. Especially all programs ("lpr", "lp", "xpp", and "qtcups") accept printing jobs both as file name supplied on the command line or as standard input. CUPS is also compatible to LPD servers when one runs the CUPS-LPD mini-daemon. See www.cups.org/sam.html#8_2 http://www.mandrakeuser.org/hardware/hcups4.html#lpdcl It accesses to LPD servers, too: www.cups.org/sam.html#8_3 http://www.mandrakeuser.org/hardware/hcups3.html#lpdsrv CUPS can also generate an "/etc/printcap" file containing the names of all printer queues, so that applications can set up a printer list, also when they are made only for LPD. But CUPS allows to set printing options in a very sophisticated way, so I would not recommend, that programs have a hard-coded call of "lpr" (as KDE 2) or even direct talking to a running LPD daemon (as LyX). I would alway give the possibility for the user to enter a printing command line and save it, so that that one can use every printing program including graphical frontends (as XPP or QtCUPS). Best would be some spooler independent way for the printing facility in the applications. Till Gael Duval wrote: > > If you have time and feel like to answer about Cups, if think it would > be great! > ------------------------------------------------------------------------ > > Subject: lpr subset standard wanted > From: Daniel Quinlan > To: freestandards-ldps@lists.sourceforge.net, lsb-spec@lists.linuxbase.org > > If possible, I would like to document the subset of lpr functionality > that can be safely used by applications into the LDPS 1.1 portability > guidelines and perhaps the LSB specification as well. > > Could someone investigate: > > - CUPS > - BSD lpr > - GNU lpr > - lprng > > and find out which options/features are supported by all of them > (and then, which options/features have the same behavior). > > If you're interested in this task, please let me know. > > A draft would need to be completed in one week if this is to make the > LDPS 1.1 beta. (The current target for LDPS 1.1 beta is January 25th.) > > - Dan --------------E7ECA23A21EA33ED14C1408D Content-Type: application/octet-stream; name="lpr-cups.1.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lpr-cups.1.bz2" QlpoOTFBWSZTWdhHwNQAAU9fgAoQXGf/sH/33+4////wUAU6JmSLy4W6y50OaEoRDRpMSbEJ iaGKMj1MRowgPUeSaGglCjATSZMp6JomQMQ0ANMhkDQAGERAp6GqaeJPQNJk0AGgB6gaAAcZ MmTEYmAEyYJkANGEYAhgEikno0SBtTaTQA0xA0AAAAAQT9O/3vNdPh0fL0YwPu2eREbk+ZiQ qPh6+OLdzFcE4Q94nCTfnsegeF7UakDt04LD4x9z/tP5bl0oIWoiKZBRG3aG6VfRSBG80cLh fMj7Ssk2kaL9iBdhr7iv/T8T1/tV0pdMNeTc/Jx4KTcTiP53nbESEJyiJpOKmzoEy+xEfT4O D17u9tu06ujDljLS1sUa5NFVaoMLmCDKXFPJjPOty7WWAiBaqS6NpCjV+tyoF+aIaCaCedn6 1mJ922si3Vx9Rf2gs0yF1qVxkw9ykNJkdcBjpbNS2ZvrjD0KGlW3Lk5quRljMVWTZUZja6Gd KZQO/IxhvYa85MCk8N/eoCWeppOhcZwnrt8qMcOrxojUwiZxTiJsXY9M9uQNeLrhQBK+ZzmJ BmsL07uf6s4S6ZihSgUH2Pzc1yQuk1WhvP33SbWbBBEfNxI9XKVMjn56dZ7B6JYowabGHDjd 1M0OtGIrcOsfah7SJxlgS5NVKvV76T+j0DAYItN4jmHwM7yKjk6uTRl5vLlNZcVEOvZi+fyY vzde1LhpCC7F0Lkcwb9UpHVuaUgqJRKid/6lrQdv0eLhpn2mLsFpFRVt9dde6Vfxa4ZeB+XP qvgVQdThQFxxCcVIG1RMECs7B9NwSvsdoiOzsKIKiKipl2YQyiQQZUiSMsGr+A9Zyy9VQqRq oQmQG20xjbG0sRjXHyKKiPHBYfChTWqH061P52HdLJmJE8lGJwKliot849KI5EWy/uiYJB8G jcDKx4H1u8qEgemGaAbpI7tdVabyGgB2NAbVwr4TYTdOH3uNVmLLTQzqCgkAghmVsMYC6FhT CBFWBXompKvySG+v2MSd7tLZxVCXWj8Xe0INqKUNhCipSRDrwDBGL2a1E8gDqB/lxYq2MWXG zNj+s9Jzuw50NTmmgLAdvWRmKTVmZ+tY3qCgotPTSKDqIZQnojbRd31ECuYLgleYNhoySjUR AkyIUInKi662qmYmIqogy63KwxZIDsqaVOaFVdO3Jq41RT+QMIQTMuYskI1WrHXS0O6sNlov 0TTK3QNJQAMly0DYys+jkmEXWEqSQ4B2F9FWPDa/ti4LKKJo8ZEg0oPXB+05bnJwKnQizrHf xjfRVXhg0ZcRkZo54+5RBrIBhrthSOhgTtQhAlbtExOyQYEwnRFtLdaIASgRvc1lhlm9pAop tgBWSbtSCyDPH/CN/pw05ibz0kxHPd1QJHUFkdQQNwQCRjbVnKgGlC0PahPCXMOTlNV8WQhb D0Gxjnmy5LwdPHTOgSc0qGtSBQ046k5+BmBjzEDCElEuA0iiyFyxyknC9VkZYmbaEDzBFdNh umQVqCHHZUK9WJiWt+A1GTWUmBLSKA2wAwtiFb5hh61fpOgeqWdausid7PW9RvmhDtmzAF2z sHF2NUkcOh1uLAnoii0URWMUvpdriqpjCWlG1YVRQMVAGWSDkIklioyKKlHwdjdaE1YmQHXs 0aWhaMtDmeOvROLCkqbLVEx5PQntCqdK6FTCklppbzMdxQtmJ7zViRIhOocb+noJ4VDARdLN L2xTSCux/4u5IpwoSGwj4GoA --------------E7ECA23A21EA33ED14C1408D Content-Type: application/octet-stream; name="lpq-cups.1.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lpq-cups.1.bz2" QlpoOTFBWSZTWZIKefgAANRfgAoQVG//uH/33+4////gUAOlo9zbc7mIkhoKm9U9Tap+oj1M j0nqYR6gZNA2p6Rpk000ekANTQmNE01T9Jojaj0hpo0AaANADTQAaaJkmk8k01PVPap5NQAA ADIAAG1BxkyZMRiYATJgmQA0YRgCGASRCNAmqfoaNI0jyj1NDTQ9IANDQACkWLvxWRqojWpN C3sKCsDiS77zK7QgZ5opi5VlfaFXhHtoc+9DJKQIWiIjEAYJPY5zXaJaqJPsdIkG91CTZdk3 bdMmzVyJ/I3/4YHBLMW7bGn0DghdywYQ1rgeMTfVui3eCxqthQ1VdDV57w6gnofRuU9TG9oV cqXVUmQcHS5cPZgg8LRetD9BwpsikM1/MXqzra6xymzaEsS+CTKHzR0LWqtSDasgfanCU4fp yLaYp409JABGXOmqwUEEGFVcEzYNwIyJZTGScoBaglmxZ0qoLIajnXBdE7mzHWEIAVLGHDo4 HgNBV7TpIgMGnFyJI1+h/ZNgiTrJPRFHEmdAUCxhg+DGzPjzQEHo13OKyiJwUPMIU0vBf+eM cotjcDsfXPcpMXOKdYj5JklVCGzAwseupGDjBRsQ9NbQHbsysJsxyiDUFOLx5LKaR4loGldN cbMlYch7CeAJAQcoS+aptslmRKyCR74xwIqtMsd52XGedE2qEJhP3lxRTPDPTgo1+Rj6dixs 4ooMS2MxEpJkimBWa7IkaFfz12EV5PCn9dFzbVZQWZ0Yp81zRJyu/KzEGqhSATCrvDyuWRHt hwk9bbF4jFEUdP4KSn1tRkgEOOhxImd7bS57jiGXa0KsK6fqSqngisvqmYJDWANOqS0JVXmY JBcuGpNl2AYQzrFhqEsB0bSSI6cKWPOMgbe5yaUbF22MJ5rOjVu/lF9KybaX6JrCd0nwOOeK aNYfvYOSAPTsglML+xwwpA3CewXazLlkpkefpXaoTrxPGMYfd27Qm0pmUrbbGIy1T4DkkHei wmOCTDSaCgzZmTEkqDOJSJTukOGTWUDtNiVVQl5DNDXdbfxHHZ2r88gmC6Un3dUuoa/UMppi Du5qnEoIuX06xzmXh31bn2VOGj/DZEebF6uUoAgDMqk8i8ZXJUUIujBmTRc522iI10py29Qm HmOD0EBOtd9kk1TIsjAldbAGEhLFYZRoITq14MorW1+PrdUFLO06wbqOmQd6LMJTaN2W1pTE tJpKRBIpajB3wKCLIEVyKGMJlScLO1UxUSIu7sTbhAmbEuS23NVDSLDOjiLuU2ZsK3DAhK3J /0ZlVi9NxQS2VpSUcmI8/fKLVkKyGhnrvTIP/xdyRThQkJIKefg= --------------E7ECA23A21EA33ED14C1408D Content-Type: application/octet-stream; name="lprm-cups.1.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lprm-cups.1.bz2" QlpoOTFBWSZTWZUatecAANVfgAoQVGf/sH/n3+4////gUAOjVvc26oaCoNTJGQ0ZQ9KaNtSe pmo0aaMmhpp6jRk0NANIyTEJ5BTyMoMI0yAaGgGgAA00I1T1AnqMTyhoNBoAABpoAAc0ZMTA BMRgRpgQYjBMmARgkSCaE1PSYU2k9QeppoGQAGgAAJQjpyZ6Bs0zJ+TtThrMRAoz5NtSZLTC mEaSF/Q7x26P6DdM82bvPAgIDUIQQpBBB7C5yTvGC5AF+DIOA4ZRVuvvdei1BqxcSX7O/AKV g9wXiyVNn9xKERWRClgRJJKIMrFM92PKNZxg5KtG9cWsj7v0GMS/ZWzk2IWkNTGszmwKJRDF 4WgiljEikG43DXVOwRP1BrqbbsL1ZvXB4Ut7EqFxSS+jC1GZmWdzK+bTPS1r7Vt5e/WQAmHw XUqEiEoLl6XDIWzZiEdDkEaFoSjpD46r+9aY2OJ1UpnpnvOgdhAgGRxFjo4HfNZf7joJgMNm 2CZQ2+qLvcEy2BSKzR4yWUZhEBxsxtoaslqon1uDmGq0JMRLCRMQNGOq/XvgLA8TiTPY/VrM Uw6E9ZmFlYUCwpOMEjdiWJvbKahKQRIoF4ekkBBPVw1a0W9lYb0Cp5hUIT7EV5VmFq9h5pCx 8F59PJeGNzpiBmjRfIryhbLRTMVMpAuqeml+qoYg0ryD0mLMVIFDcCBDNlBL9CYXD7O3Kztz fMZXm5BCeCilfa71pURLou3i6rVeWHSpcKlvErFx+pA5KGGoFqBCLoZiE+mwIkPX8LGIwTdI UkwVIsE2ejUa9sxXZ8bP4YpQfg+BAfG6k8oIpBE6ve+QwM79+L232/X3KYhmzENZGfKuFqlv Pqnlqlnr89lsnq2rcfURrpyrcx1SlsJI7BJE59bYrh87bE+aFlq3rtM7dq4Y9PWw7n7zLluf aNdVo0J397jmNzsKAk0dOVBvD177A9hFhC5IYLlKJbPip0qDIrG97zooNMOeYC5RZsgXJCOW qbTaMa9k1zpZOiz4lUlBZooyHDh8bgdZKQm14GpyMmi6V0myIgGUnwsb/4ln3cOPSK9d5KOH mp5hmk1jRZjcuzbdS4pCzJ25CW/tl/pi3+Ne0lhzGyWGHYtMGgahR16lmqShNtl0d/eBNhfB GPMrWXlHz4QgtMULdxUVHe8OeRU0QHFJZ0urXqRYyT1Ihhs0+Aa0pllnMOg85VVB5MejQVgv lpSQmWmZTad+V8zKtc7jQCnVUUFGVHdLDTYZYoTbssKVwmLiK+iDV5QVNX9mbS7BuRWBSK8T vsPFtDYJltIkK49OgMbOUQR4ZolWLP8XckU4UJCVGrXn --------------E7ECA23A21EA33ED14C1408D Content-Type: application/octet-stream; name="lpc-cups.8.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lpc-cups.8.bz2" QlpoOTFBWSZTWeWHeFQAARlfgAoQVGf/8P/n3+4////gUAUCMvXRnGd67p68nXqGJTJT9KeR oYVP0aEyCDI9TT1NkaR5NDSNPUGmiTAmmkBpNGiYQNBo0A0YmgZASmkxQ0QGppGUzU2UYRhG ANRoANNBIkKaIyNNDRk0AaAAZNAAAASSE1NqaIek2oAekZHqGgMmgGgACIn5/cTHbpaRbma1 HxTczBwXBrN+KKH6YRzJokO0+wy4eP5/hHdXsW3dJDXn74uD7mlQ3OFGYgikkoWhJENvWhRe wzZ/cfUWjFoFy9XaRhqforbkWwztLhbA9f6euMVcgaPo2S4eSzdwkEdzOGUKBIzFB5Bpx1/D dhbQUpz1Fw2HhpUtsi5WebclHDhBEpLFLh9vMoibRg5ywnuWe9NYPqpmZKJFmwIEXPaLP6W+ e/SgcMtY+Ilj/cNDrZZ8zn5aYRmn1UTl3MKkM65yNZ0I7jtotZPIf3FmhRum2lZ2c3GRvqLY abjYuF+rsqJyP69yAbZ2vXMShsiuXRrhSNpqzr+T0EkgpmXnobs0wrJUgLQY9O7qW98zjvXs MVOisLXHGReO1AKGluk5yYSw0yXeYyADBfqcQJjM0epBwCMxcr3IOgSkPSHAZU48K4QMH1v+ jkFhaiw9wZQ6AjlIeJUHGzIq83DGOgUC6IY/jlva/TVscbMvbEUjBTORCncqiioop4oCfZ2q 8SKRBSkABXuhgG/HR8lYNCzsR0p7QcMFRCLG1expq7rGm4KXfkdrrraxEWXHOgvmiSgbwBZE F8mDXT17ESWDoYgC7BhnIQfWb88C5D4kQupMauA9Yl+qiRBWxCkD2Bhs6y5EnkMRY8MnC6Zj FYTHZXmz3LciCuTweTTpmMdoHJmVAme+dz3AQ22ViHUN23pGV30RODFE/4fI5McbSNdhvO5Q cZS4gt0sQmb+BHL1uOgxorNmvOn8y3FGAIW9WVgQJYO/SOYo2k3q0mfZ22xLqQSmk6rmA8Ao RdJ3/1BWQnubelSRIEIIFXvgJPkGlPQ523wrxApJdUK4Or32dhmTMl4FjlpfosQqcxpKKC4g LuosIqb9UdbEQ1XBGqA8Ge2gyAMgF6kkOsFKbbok65JGBSdEUBmhcVGt9jaDYkRLDBbLqxnO hCDo7s2iqw6Zve9A2J4sFLHBCcvyNEeq/fCUbxdhCaxCb7d5Id49bY9L/TqpTuINuzs747Vr LdBVq/eQF/GBW7lBILCKRhAa9TtUVv8skjykcRRQnAoaF/B8EZPqrYdZzMxMyLVUWR0C3cLs NkQ8CKs7OsE6gceoeZlYuMfemCYZC3oaiHjB0OnEOHPw7e1Qq6dGV6kT7oFaTwwMZWikZRnN TUMYoVh03gmi3dpjbj3R9/f7BLXNeC2RDV1nIHFBnCFdusJzqdIJChhmNGBSpfRaiwq3G0V9 pFSoDY0O3Abq1XmwkWitCsVEilxTmjnHhylFUxOGBycbpopJlKLuRq+mj9SONWRilSOQWijC X/JHLZFKLGGJwvWx2fWGm6288ZBkGJvtd5M0ajijxe0ghYbBtq+XGYuFIxraW2NJ2Z7ygJEm nCESzzTGGTOUbGZskVDKlkPnxo309jQxFiYaO0oYPXU4SD4E478J5JXVg1YOKIRPPCeZHIMA oAtpHTj8zm14Rim3T12zZpDvR48PEFaWEHONciIzsr7WoUCFX/F3JFOFCQ5Yd4VA --------------E7ECA23A21EA33ED14C1408D Content-Type: application/octet-stream; name="lp.1.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lp.1.bz2" QlpoOTFBWSZTWbFOQW4AAZBfgAoQXGf/sH/n3+6////wYAZBUI+2Lxc17t3su3Ierbg00giZ qZGjRkyT1DJpPFDag2UZqGNNQAaEABGKRP1T0amjyT1PU00AAGgaaADU9TEo2jVDTAmEGmmE YgAGQGQaBJqUGqehNR6j1HlBtQ00ZGgA0AAABxkyZMRiYATJgmQA0YRgCGASJCMk0yVPYU9T 1NT2lD8kEaaYIwRkZGT0MRN/LXu4EaT4+Xn7uX3HO/UPTwxsHNVGopmKHzVmtQ4F66MGlkdS h8CrCIM7/UgBerhaiDJbxhzj2Igf9J+Q6qzTZM+lrHL/XK2hvpv4xC5EzkIliIhCghFnPcWY 30hem1e6OhmqJ4haP2NQqEgyaBPfzWognhkvVs9gsvUulGR5/mCvlGtwTsd3NLznY+sRBM2r qcwUIRedsAUwKqbyT3kRVz9CBJ4hJDBr2y3W7c2n80V35lmWqttzF61WIiIjMsekKmH4erpD WHpBSuKWJ8+TR9CehyW+LA9yqmFmc1KNcOLYIzZBbnS3IpGL2oUTCG9zw8LvskMm+AZPxlFe ZrovBit3Qb39QlcKhqbzS46h7rVTSz+u07Zq1QccmpQ+EAuGbBTDM16qo7AbVLA0qoL2ZwjD XDO2+VzFTRuTzPzZVcNMUDKZHc95ACYrlWUVBxCWcFF8FxG8gUHaIU8IuTPHtbTkjw47/WG3 H5wrGUYNPHCoaguMxFJAZHcIThwQEjRifM6LQtHQ82Ry0xfEwZrc19azEgZwEQC8yG4RjbsK mZSPbA5I6WTabPcjh3oOBQ9jIu5RyGEysCI0WgW/paBvBkMhKImOp22uUTjCs/ksiDToGVmp +EMaYi8DZmqq7edwrFAkEfw17MX2714qqZc43e35AKrheKaj0EaGKhLt3Z5RiC97PNsYkIS9 c9ENGObleoCJQH+svT72hYOyiLeDGQhIGDBKMrsi9vlU4KeY9GNbPmlE7WVWGCII6swUjigg OQwVyIUMirRSw6vKCixTPzgibqvK0QqRBDrOGvAqQz44RQ0SNM2PU4j72NnTz2kyGCzOQjKV iqiKqIxWCqTjOTm8/eu5uPlfn8PDaxWgmhFijznhYOWT7LT3p86wu38+onLsIZNInNZEkBWU RfYMnFVGdREYE2xvKXMWqv3ZOVcwh+Azt5gVi9bjZwQqLRcjdIg2v+fJBdkJ9rJbBObhis+t 6ZumlLEpp+dsFarcmapKBaoaoaKp3kzmOGWBmotagtRheX6biY21a63zJ7WdpcKGzbxvrBMX GRCCxfH+QRcyLWlfawpMql44O28gkW4Q6hQP42K0ZTKlENjCozpOG4YB1emlONo3OxeYEVPZ ETkENDE2qugEcszmpENSkKvRzpgjJXagv1LeBw/0EGwoKgEboTauSc7E0jc9gFvJibptNhlo uq7kYqMUiyV0C7XR18BwioCrlESTkaHQTDSDP3ZQ55HYLCCQfDGEkikSw2nRr3mhGtrcEzbq ubZJDL9TrML4hSrdgATQDDq8mVNrhmVg7D2c+rMzyrkiKYCOhh1K7XxybFVSQ0MLNtUUwbaj 4aFQm0gGQTOsGaXKtV4RkSqfdw24EREy6AlpXLEyCw+qUBoiUNzUluHHotpWcDMh0Nkikyq3 bcbDJli+RfpgLhkREicRIkSLhCzLVtamMMCOaiW5aL0SyEp4vTmyNmy4zFoKI1KoM7CsrSq3 98U3IcHD/pJtOA39fVe8WQdLH4UqT7OSx9E1T0DNoaBpE2SXOULFHS7yUWH1lQlyWIfgGEF+ P77A740cDukFxqfTwNwbwno03Z/fQAs1CwpVKrXYcgUxskwbY+L/K0kJowoSz76ppSPMMbC4 PxchS3ruwPEonMQIyQNXYPLRSrCBgUe/e3YVSoaKWDeZzOccBE23FYKc3nveeylIRhhpeUyu QdFRxjTaFETKDrSaNIONEbo356zNMJzI0yqKhMCt2d4R7wyAPBkqytovxcbBV17qcDTJCkxh RnootNNmUKO8t9SmnXYoBBBcTxiL8JqZD8FDelxvWbvtLkLULmuLhriMUEs1KJL6P/AWCSFR VRlK7Neoia8AGY0RfdcXAOKhZgjCCWBdVbFgntt/xdyRThQkLFOQW4A= --------------E7ECA23A21EA33ED14C1408D Content-Type: application/octet-stream; name="cancel.1.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cancel.1.bz2" QlpoOTFBWSZTWbFOQW4AAZBfgAoQXGf/sH/n3+6////wYAZBUI+2Lxc17t3su3Ierbg00giZ qZGjRkyT1DJpPFDag2UZqGNNQAaEABGKRP1T0amjyT1PU00AAGgaaADU9TEo2jVDTAmEGmmE YgAGQGQaBJqUGqehNR6j1HlBtQ00ZGgA0AAABxkyZMRiYATJgmQA0YRgCGASJCMk0yVPYU9T 1NT2lD8kEaaYIwRkZGT0MRN/LXu4EaT4+Xn7uX3HO/UPTwxsHNVGopmKHzVmtQ4F66MGlkdS h8CrCIM7/UgBerhaiDJbxhzj2Igf9J+Q6qzTZM+lrHL/XK2hvpv4xC5EzkIliIhCghFnPcWY 30hem1e6OhmqJ4haP2NQqEgyaBPfzWognhkvVs9gsvUulGR5/mCvlGtwTsd3NLznY+sRBM2r qcwUIRedsAUwKqbyT3kRVz9CBJ4hJDBr2y3W7c2n80V35lmWqttzF61WIiIjMsekKmH4erpD WHpBSuKWJ8+TR9CehyW+LA9yqmFmc1KNcOLYIzZBbnS3IpGL2oUTCG9zw8LvskMm+AZPxlFe ZrovBit3Qb39QlcKhqbzS46h7rVTSz+u07Zq1QccmpQ+EAuGbBTDM16qo7AbVLA0qoL2ZwjD XDO2+VzFTRuTzPzZVcNMUDKZHc95ACYrlWUVBxCWcFF8FxG8gUHaIU8IuTPHtbTkjw47/WG3 H5wrGUYNPHCoaguMxFJAZHcIThwQEjRifM6LQtHQ82Ry0xfEwZrc19azEgZwEQC8yG4RjbsK mZSPbA5I6WTabPcjh3oOBQ9jIu5RyGEysCI0WgW/paBvBkMhKImOp22uUTjCs/ksiDToGVmp +EMaYi8DZmqq7edwrFAkEfw17MX2714qqZc43e35AKrheKaj0EaGKhLt3Z5RiC97PNsYkIS9 c9ENGObleoCJQH+svT72hYOyiLeDGQhIGDBKMrsi9vlU4KeY9GNbPmlE7WVWGCII6swUjigg OQwVyIUMirRSw6vKCixTPzgibqvK0QqRBDrOGvAqQz44RQ0SNM2PU4j72NnTz2kyGCzOQjKV iqiKqIxWCqTjOTm8/eu5uPlfn8PDaxWgmhFijznhYOWT7LT3p86wu38+onLsIZNInNZEkBWU RfYMnFVGdREYE2xvKXMWqv3ZOVcwh+Azt5gVi9bjZwQqLRcjdIg2v+fJBdkJ9rJbBObhis+t 6ZumlLEpp+dsFarcmapKBaoaoaKp3kzmOGWBmotagtRheX6biY21a63zJ7WdpcKGzbxvrBMX GRCCxfH+QRcyLWlfawpMql44O28gkW4Q6hQP42K0ZTKlENjCozpOG4YB1emlONo3OxeYEVPZ ETkENDE2qugEcszmpENSkKvRzpgjJXagv1LeBw/0EGwoKgEboTauSc7E0jc9gFvJibptNhlo uq7kYqMUiyV0C7XR18BwioCrlESTkaHQTDSDP3ZQ55HYLCCQfDGEkikSw2nRr3mhGtrcEzbq ubZJDL9TrML4hSrdgATQDDq8mVNrhmVg7D2c+rMzyrkiKYCOhh1K7XxybFVSQ0MLNtUUwbaj 4aFQm0gGQTOsGaXKtV4RkSqfdw24EREy6AlpXLEyCw+qUBoiUNzUluHHotpWcDMh0Nkikyq3 bcbDJli+RfpgLhkREicRIkSLhCzLVtamMMCOaiW5aL0SyEp4vTmyNmy4zFoKI1KoM7CsrSq3 98U3IcHD/pJtOA39fVe8WQdLH4UqT7OSx9E1T0DNoaBpE2SXOULFHS7yUWH1lQlyWIfgGEF+ P77A740cDukFxqfTwNwbwno03Z/fQAs1CwpVKrXYcgUxskwbY+L/K0kJowoSz76ppSPMMbC4 PxchS3ruwPEonMQIyQNXYPLRSrCBgUe/e3YVSoaKWDeZzOccBE23FYKc3nveeylIRhhpeUyu QdFRxjTaFETKDrSaNIONEbo356zNMJzI0yqKhMCt2d4R7wyAPBkqytovxcbBV17qcDTJCkxh RnootNNmUKO8t9SmnXYoBBBcTxiL8JqZD8FDelxvWbvtLkLULmuLhriMUEs1KJL6P/AWCSFR VRlK7Neoia8AGY0RfdcXAOKhZgjCCWBdVbFgntt/xdyRThQkLFOQW4A= --------------E7ECA23A21EA33ED14C1408D-- From kingdon@panix.com Sat Jan 13 19:28:16 2001 From: kingdon@panix.com (Jim Kingdon) Date: Sat, 13 Jan 2001 14:28:16 -0500 (EST) Subject: [Freestandards-ldps] Re: [Fwd: lpr subset standard wanted] In-Reply-To: <3A60B44C.1A120B8B@mandrakesoft.com> (message from Till Kamppeter on Sat, 13 Jan 2001 21:02:20 +0100) References: <3A5E3551.8BCF4B84@mandrakesoft.com> <3A60B44C.1A120B8B@mandrakesoft.com> Message-ID: <200101131928.OAA16161@panix6.panix.com> > See the manual pages of the commands (attached, use "bunzip2 ; > man ./" to read them). I suspect we just want the lpr command. Although the CUPS lpr manpage does look like a good place to start (-C, -J and -T seem to differ in meaning somewhat; I'm not sure we want to standardize -r because of the potential for losing someone's file in a paper jam, as noted in the LPRng manpage; -o doesn't seem to be supported by LPRng). But other than that the CUPS options seem to also be available in LPRng. > CUPS is also compatible to LPD servers when one runs the CUPS-LPD > mini-daemon. See Not an LSB or LDPS issue, I don't think. > I would not recommend, that programs have a hard-coded call of "lpr" > (as KDE 2) We might want to recommend that applications give the user the option of specifying a command (as Netscape does). But we should also recommend that they default to "lpr", as Netscape does (programs should be able to print in a simple way without any configuration and the "lpr" command line is the portable way to do that). > even direct talking to a running LPD daemon (as LyX). Heavens no. We don't want to require that an lpd daemon be present any more than we require that an SMTP daemon be present (the latter *was* the subject of much discussion). See http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/spec/command/sendmail.sgml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=lsb for what we have done vis-a-vis sendmail. From mcneil@valinux.com Mon Jan 15 18:40:18 2001 From: mcneil@valinux.com (Scott McNeil) Date: Mon, 15 Jan 2001 10:40:18 -0800 Subject: LinuxWorld New York Message-ID: <3A634412.7F0FC9FA@valinux.com> We still need volunteers to staff the FSG booth for the following dates/times: Wednesday, January 31 (1) 2pm - 4pm (1) 4pm - 6pm (1) 3pm - 4pm Thursday, February 1 (1) 1pm - 2pm (1) 2pm - 4pm (2) 4pm - 6pm Friday, February 2 (1) 12pm - 2pm (1) 1pm - 3pm (2) 2pm - 3pm (1) 3pm - 5pm Volunteers will receive a free pass to the show, IDG/LinuxWorld VIP party, and at least one T-shirt from our generous Corporate Sponsors. Scott -- Scott McNeil , From gk4@us.ibm.com Fri Jan 19 20:59:25 2001 From: gk4@us.ibm.com (gk4@us.ibm.com) Date: Fri, 19 Jan 2001 14:59:25 -0600 Subject: The review of LSB v0.4.2 ends this coming Thursday January 25th Message-ID: <852569D9.0076C7EA.00@d54mta01.raleigh.ibm.com> The review of LSB v0.4.2 ends this coming Thursday January 25th. Everyone is encourage to read and comment on the specification. http://www.linuxbase.org/spec/lsbreview.html The LSB workgroup will be meeting on Tuesday January 30th in New York city to review the comments and plan on the delivery of the LSB v1.0 specification. http://www.linuxbase.org/talks/20010130.html George Kraft IV gk4@us.ibm.com 512-838-2688; t/l 678-2688 IBM Linux Technology Center http://oss.software.ibm.com/developerworks/opensource/linux/ FSG's Linux Standard Base http://sourceforge.net/projects/lsb/ From Johannes Poehlmann Tue Jan 23 14:07:43 2001 From: Johannes Poehlmann (Johannes Poehlmann) Date: Tue, 23 Jan 2001 15:07:43 +0100 Subject: confcall followup: [PROPOSAL V2] (Ch.16 FHS) file/dir permissions In-Reply-To: <20010104134004.A28627@caldera.de>; from johannes@caldera.de on Thu, Jan 04, 2001 at 01:40:04PM +0100 References: <20010104134004.A28627@caldera.de> Message-ID: <20010123150743.A9860@caldera.de> (As discussed in the last LSB conference call) ---------------------------------------------------------- Reworded proposal to add the following to chapter 16: ( comments from Alan Cox: changes of #3) ( comments from John Terpstra: Add #6) In this Chapter "System" means a "LSB compliant system" and "application" means a "LSB compliant (third party vendor) application". 1. Directory Write Permissions o The application must not depend on having directory write permission outside /tmp, /var/tmp and it�s home directory. o The application must not depend on owning these directories. o The system may restrict directory write permissions for these directories by setting the "sticky bit" for them. ( To prevent the application to remove "foreign" files, e.g. a empty .rhosts file owned by root.) 2. File Write Permissions The application must not depend on file write permission on files not owned by the user it runs under with the exeption of its personal inbox /var/mail/ 3. Read Permissions and Execute Permissions o The application must not depend on having read permission to every file and directory. | o The system must grant to the application read and execute | permissions needed to use all system interfaces (ABIs) | mentioned in the LSB document and included standards. 4. Suid and Sgid Permissions The application must not depend on suid/sgid permissions on a file. Instead, the system is responsible that all system commands are just correctly doing their job and have the permissions needed. Rationale: Let us make security officers happy. Lets give them the freedom to take sgid/suid perms away, as long as they do not break the systems funtionality. | 5. Privileged users | | Application may not depend on running as a privileged user | | [ If we can not agree on that (which I am in favor of), let us | at least state this as a minimum: | | If an application wants to run under a privileged user, | then | o The reasons must be outlined clearly | o It must be prominently and verbatimly stated in all announcments | of the application that "this application demands security | privileges, which could infere with system security". | o The application may not contain binary only software. | ] | 6. Changing permissions | | Application must not change permissions of files and | directories not beeing part of their package 7. Removable Media (Cdrom, Floppy,...) o The Systems may use mount options "noauto", "nouser", "nosuid" and "nodev" for removeable media. Also "uid=X", "gid=X" may be used with a non-zero uid/gid value X. Rationale: allow running applications from removable media, but allow systems to prevent application from bad behaviour. 8. Run-from-removable media applications o They must not depend on logging in as a privileged user. 9. Installable applications (This paragraph should possibly be part of Chapter VII. - Package Format and Installation) On Installation, they must not depend on BOTH to o log in as user root o run a self-supplied binary install routine Rationale: Let us make security officers less unhappy. Rationale/Problem: LSB says nothing about File Permissions. o This makes it possible to set up an LSB-conforming package and a LSB conforming Linux system where the application can not run on the linux system. o LSB-conforming systems should be allowed to use very restrictive permission schemes, not to make security and LSB a contradiction. Consequences: o LSB conforming applications should run with very restrictive file permissions o LSB-conforming systems should not be required to give much file permissions. -- ______ ___ / ___/__/ / Caldera (Deutschland) GmbH / /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany /_____/_/ /____/ software developer / lsb project ==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399 From orjrotbh@mail.ru Tue Jan 23 20:17:32 2001 From: orjrotbh@mail.ru (orjrotbh@mail.ru) Date: Tue, 23 Jan 2001 12:17:32 -0800 Subject: Cheap developers for your project available Message-ID: <200101232017.MAA31052@surfer.oakweb.com> Dear IT Manager: Please consider deploying our highly skilled off-shore programmers on your e-commerce and software development projects. They develop software for: ALL WINDOWS AND UNIX PLATFORMS databases, networks, and languages, plus Perl, PHP, C++, ASP, Cold Fusion, Java, WAP, XML, MS Access, SQL, Shopping Carts, and the Internet. Typical rates are $15 to $20 per hour. They are fast, professional, inexpensive, cheap, and available immediately. Please call me, or reply this e-mail. http://softomate.da.ru Thanks! Paul USA: +1 (213) 5162593 PS. You are already removed! PPS. In Europe? Please call +39 3480612212 From mcneil@valinux.com Wed Jan 24 00:40:22 2001 From: mcneil@valinux.com (Scott McNeil) Date: Tue, 23 Jan 2001 16:40:22 -0800 Subject: FSG/LinuxWorld - Last Chance! References: <3A634412.7F0FC9FA@valinux.com> Message-ID: <3A6E2476.FB617C41@valinux.com> All staff positions have been filled except for the following two: Thursday, February 1: 4-6pm Friday, February 2: 2-4pm Volunteers receive free passes to the show, free passes to the huge IBM party on Wednesday, free passes to the IDG VIP party on Thursday, free admission to all four keynotes (including Dirk Hohndel & Larry Augustin), free admission to the Golden Penguin Bowl (hosted by Nick Petreley), a free T-shirt, and other stuff that is simply too amazing to convey in ascii. Just reply to this email with the time you are available to assist and we will register you for the show. See you next week! Scott -- Scott McNeil Free Standards Group www.freestandards.org From johannes@caldera.de Wed Jan 24 16:55:13 2001 From: johannes@caldera.de (Johannes Poehlmann) Date: Wed, 24 Jan 2001 17:55:13 +0100 Subject: V4 [Partial withdrawal of PROPOSAL] Change Chapter 17 (cron) Message-ID: <20010124175513.A1108@caldera.de> 1. We want to uphold one part of the proposal, which was already sent out separately: Date: Thu, 7 Dec 2000 16:02:25 +0100 From: Johannes Poehlmann To: lsb-spec@lists.linuxbase.org Subject: [PROPOSAL] Get rid of the cron.hourly dir Message-ID: <20001207160225.A11177@caldera.de> Our reasons are: o because many parallel cron scripts cause a big computational load, it should be possible to serialize these scripts. This would be risky when using cron.hourly: What if the serialized scripts need more time then one hour ? o we want to allow cron to optimize away hourly disk accesses, as vixie-cron with a patch from debian already does. o implementing anacron-like functionality produces unnecessary overhead if cron.hourly is in place (or the anacron-like functionality had to be switched off for cron.hourly resulting in inconsistent behaviour). 2. As a consensus could not be reached, we do withdraw the rest of the mentioned proposal. Instead we propose to legalize our proposed concept (using symbolic links to a common scripts repository) as we would not like to give it up for Caldera OpenLinux. proposed new (and shorter ..) wording: The directories /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly may also contain soft links to a centralized scripts repository. If existing, this directory has to be named /etc/cron.scripts. -------- Task for the proposal http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=18043&group_id=1107&group_project_id=3049 http://lists.debian.org/lsb-spec-0008/msg00000.html lsb-spec mailing list: <20000801154116.A15227@caldera.de> On Tue, Aug 01, 2000 at 03:41:59PM +0200, Johannes Poehlmann wrote: > This Proposal is a repost of "Comments on Chapter 17 (cron) > of the LSB Spec", sent out 2000 June 12 to the lsb-spec list > > ============================================= > > PROPOSAL to change Chapter 17 of the LSB Spec: > > common script repository, init-like symlinks, directory naming > > > > 1 It is desirable to control the order of execution of the scripts > put in one of the "periodic scripts directories" ( /etc/cron.daily etc.). > > This can be done by adapting the naming scheme used inside > of /etc/init.d, using two digit prefixes, which control the order > of execution. > > 2 It should be possible for the local sysadmin to move the scripts from > one "periodic scripts dir." to one other, to control frequency of execution. > > 3. Both requirements 1. and 2. make it difficult for package managers to > cleanly remove or update because the script names and path can change. > > 4. This is why Caldera uses a common cron script repository > (/etc/cron.d/lib in OpenLinux 2.4) and uses soft links to these > repository from the periodic scripts directories. (modeled > after /etc/init.d/) The soft links must be named XXname, where > XX is 2 digits and name is the name of the script pointed to. > > Example: /etc/cron.d/Daily/40cleandir ->../lib/cleandir > > The local system administrator now can rename and move these > soft links inside the periodic scripts directories, but the > package manager can get the information which soft links point > to which script. As the scripts are part of a package, the > package manager could completely control these soft links. > > 5. /etc Name space pollution > > The actual proposal enforces 5 cron related directories in /etc. > (Or even 6 if our cron script repository idea is used). This can > get even worse, if somebody wishes more periodic scripts directories, > say /etc/cron.biweekly. > > This is why we propose to keep the historical place /etc/cron.d/ > and put the following directories inside: > > /etc/cron.d/ > � > +-Monthly periodic scripts directories (Capitalized Names) > +-Weekly > +-Daily > +-Hourly > +-[A-Z]* more periodic scripts directories allowed > | > +-scripts cron scripts repository > +-tabs cron tab snippets dropped by packages > ( is /etc/cron.d in the lsb-spec ) > ----- End forwarded message ----- -- ______ ___ / ___/__/ / Caldera (Deutschland) GmbH / /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany /_____/_/ /____/ software developer / lsb project ==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de Caldera OpenLinux phone: ++49 9131 7192 336, fax: ++49 9131 7192 399 From mcneil@valinux.com Fri Jan 26 20:44:20 2001 From: mcneil@valinux.com (Scott McNeil) Date: Fri, 26 Jan 2001 12:44:20 -0800 Subject: FSG LinuxWorld Speakers References: <3A634412.7F0FC9FA@valinux.com> Message-ID: <3A71E1A4.AB214832@valinux.com> If you would like to speak at the San Francisco LinuxWorld in August about the FSG, LSB, Li18, LDPS, FHS, etc. please let me know. I will work with you to help make sure that your proposal gets approved. All proposals are due no later then FEBRUARY 16, 2001. http://www.linuxworldexpo.com/papers.html IDG gives speakers free show passes, complimentary lunch each day of the show, a cool jacket, T-shirt, bag or other show goodie, and usually some other stuff. Scott -- Scott McNeil Free Standards Group www.freestandards.org From wichert@cistron.nl Sat Jan 27 09:59:33 2001 From: wichert@cistron.nl (Wichert Akkerman) Date: Sat, 27 Jan 2001 10:59:33 +0100 Subject: [PROPOSAL] (Ch.16 FHS) be more specific on file/dir permissions In-Reply-To: <20010104184232.B8891@caldera.de>; from johannes@caldera.de on Thu, Jan 04, 2001 at 06:42:33PM +0100 References: <20010104134004.A28627@caldera.de> <20010104184232.B8891@caldera.de> Message-ID: <20010127105933.B12907@cistron.nl> Previously Johannes Poehlmann wrote: > Yes, as local sysadmin I want to be able to place a empty rhosts file > (owned by root) in home directories, to prevent users from opening > rsh security holes. To prevent the users from deleting .rhosts, > I need the sticky bit on the home directory. A homedirectory is owned by the user anyway, so he can easily remove that sticky bit. Or do you have home directories owned by root and have a seperate group for each user? Wichert. -- _________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | wichert@cistron.nl http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From ke@suse.de Wed Jan 31 15:33:38 2001 From: ke@suse.de (Karl Eichwalder) Date: 31 Jan 2001 16:33:38 +0100 Subject: Build the SPEC on SuSE Linux Message-ID: [I'm not subscribe to the list; please, Cc answers.] At http://www.linuxbase.org/spec/build.html you're asking how to build the spec on other distributions. Please, add this to the web page: On SuSE Linux 7.1 (and ealier, but I didn't test it) you'll habe to install the well know packages from the serie SGML with YaST or YaST2 (jade, docbkdsl, docbktls). If you're interested in PostScript out put, please install from the serie TeX/LaTeX the teTeX packages and jadetex. After installing these package, just call: db2html spec.html db22dvi spec.html or db2ps spec.html For more options please try 'db2x.sh --help'. It looks to me as if not all files are properly checked into the CVS repository; these files are missing after a cvs co: sysinit/sysinit.sgml sgmlspec/sgmlspec.sgml In addition, please fix this small syntactical error: Index: command.sgml =================================================================== RCS file: /cvsroot/lsb/spec/command/command.sgml,v retrieving revision 1.10 diff -w -u -u -r1.10 command.sgml --- command.sgml 2001/01/18 22:58:53 1.10 +++ command.sgml 2001/01/31 15:32:22 @@ -19,8 +19,6 @@ The behaviour of the interfaces described in this section are specified by the following Standards. - - -- Linux Frechet 2.2.18 #1 Fri Jan 19 22:10:35 GMT 2001 i686 unknown 4:21pm up 1 day, 6:05, 8 users, load average: 0.11, 0.27, 0.18 work : ke@suse.de Karl Eichwalder home : keichwa@gmx.net From tytso@mit.edu Wed Jan 31 12:40:52 2001 From: tytso@mit.edu (tytso@mit.edu) Date: Wed, 31 Jan 2001 07:40:52 -0500 Subject: V4 [Partial withdrawal of PROPOSAL] Change Chapter 17 (cron) In-Reply-To: <20010124175513.A1108@caldera.de> (message from Johannes Poehlmann on Wed, 24 Jan 2001 17:55:13 +0100) References: <20010124175513.A1108@caldera.de> Message-ID: <200101311240.f0VCeq802735@snap.thunk.org> Date: Wed, 24 Jan 2001 17:55:13 +0100 From: Johannes Poehlmann Sorry for not getting back to you sooner; I've been way behind on my e-mail lately.... 1. We want to uphold one part of the proposal, which was already sent out separately: Date: Thu, 7 Dec 2000 16:02:25 +0100 From: Johannes Poehlmann To: lsb-spec@lists.linuxbase.org Subject: [PROPOSAL] Get rid of the cron.hourly dir Message-ID: <20001207160225.A11177@caldera.de> Our reasons are: o because many parallel cron scripts cause a big computational load, it should be possible to serialize these scripts. This would be risky when using cron.hourly: What if the serialized scripts need more time then one hour ? Actually, the easy way to solve the computational load problem is to observe that cron.hourly merely states that the scripts need to be run about every 60 minutes; that the only guarantee which is made. But they don't have to be all run at the same time; so instead of making them be serialized, a cron program could simply make one run at 7 minutes after the hour, and another run at 14 minutes after the hour, etc., and they would be compliant. (And separating the start of each cron.daily entry by 30 minutes would probably be a good idea too... this would be a very easy option to add to the run-parts program.) o we want to allow cron to optimize away hourly disk accesses, as vixie-cron with a patch from debian already does. I've in the past showned that it's possible to code cron such that it doesn't require hourly disk accesses. (i.e., hold open a file descriptor for the /etc/cron.hourly directory; then every hour or so, do a fstat to check the modtime; this won't cause a disk access.) Yes, it requires making a code change. On the other hand, enough other changes need to be made to a Debian system (and I suspect most systems) before they will be laptop battery friendly anyway, so this argument doesn't seem to carry much weight, since at the moment, getting rid of cron.hourly won't help you much anyway. I'm running Debian/Woody on my laptop now, and.... * There's a crontab entry for exim which fires every 30 minutes, regardless of whether you have networking up (dumb, dumb, dumb, dumb). This causes the atime for the exim inode to be modified, but worse yet, the fact that the crontab entry specifies that the entry should run under the mail user, that means that there are multiple syslog messages from the pam message hitting /var/log/messages. The fundamental issue is that running the exim -q needs to run out of a special long-term running process, ala sendmail -bd, if you want to avoid waking the disk every time you want to try to flush the queue; merely running a non-root job out of crontab guarantees disk activity (because of the syslog writes), even if the program doesn't do anything else. * The syslogd is configured to create syslogd mark messages every 30 minutes (which of course is not synchronized with the above 30 minute exim queue flush), which in combination to the above causes the disks to spin up at least four times an hour. There may have been other laptop unfriendly daemons that were causing my disk to wake up, but at this point I gave up looking. Suffice it to say that there were a lot of problems.... o implementing anacron-like functionality produces unnecessary overhead if cron.hourly is in place (or the anacron-like functionality had to be switched off for cron.hourly resulting in inconsistent behaviour). What sort of "unnecessary" overhead are you referring to? Is this the need to spin up the disk to write anacron control entry file (i.e., /var/spool/anacron/cron.hourly)? Note though that anacron doesn't support any granularity finer than one day anyway, and so if a program were to put an entry into /etc/cron.d, they wouldn't have anacron functionality anyway --- and even if you put an entry into /etc/anacrontab (and the LSB doesn't guarantee the presence of anacron), you can't get one hour resolution anyway. So not having anacron functionality for cron.hourly doesn't seem like either a huge inconsisntency, given that there's absolutely no way to provide that sort of functionality anyway..... If people really don't want cron.hourly, we can remove it at least for LSB 1.0. But I would like to hear some other opinions about whether or not we should keep cron.hourly. What do folks think? - Ted From Oldies@murphy.debian.org Tue Jan 2 08:20:05 2001 From: Oldies@murphy.debian.org (Oldies@murphy.debian.org) Date: Tue, 02 Jan 2001 02:20:05 -0600 Subject: 01-01-2001 Message-ID: <36893.097280659720100.291204@localhost> Oldies Online Casino - Happy New Year!!!

-- Linux Frechet 2.2.18 #1 Fri Jan 19 22:10:35 GMT 2001 i686 unknown 4:21pm up 1 day, 6:05, 8 users, load average: 0.11, 0.27, 0.18 work : ke@suse.de Karl Eichwalder home : keichwa@gmx.net From tytso@mit.edu Wed Jan 31 12:40:52 2001 From: tytso@mit.edu (tytso@mit.edu) Date: Wed, 31 Jan 2001 07:40:52 -0500 Subject: V4 [Partial withdrawal of PROPOSAL] Change Chapter 17 (cron) In-Reply-To: <20010124175513.A1108@caldera.de> (message from Johannes Poehlmann on Wed, 24 Jan 2001 17:55:13 +0100) References: <20010124175513.A1108@caldera.de> Message-ID: <200101311240.f0VCeq802735@snap.thunk.org> Date: Wed, 24 Jan 2001 17:55:13 +0100 From: Johannes Poehlmann Sorry for not getting back to you sooner; I've been way behind on my e-mail lately.... 1. We want to uphold one part of the proposal, which was already sent out separately: Date: Thu, 7 Dec 2000 16:02:25 +0100 From: Johannes Poehlmann To: lsb-spec@lists.linuxbase.org Subject: [PROPOSAL] Get rid of the cron.hourly dir Message-ID: <20001207160225.A11177@caldera.de> Our reasons are: o because many parallel cron scripts cause a big computational load, it should be possible to serialize these scripts. This would be risky when using cron.hourly: What if the serialized scripts need more time then one hour ? Actually, the easy way to solve the computational load problem is to observe that cron.hourly merely states that the scripts need to be run about every 60 minutes; that the only guarantee which is made. But they don't have to be all run at the same time; so instead of making them be serialized, a cron program could simply make one run at 7 minutes after the hour, and another run at 14 minutes after the hour, etc., and they would be compliant. (And separating the start of each cron.daily entry by 30 minutes would probably be a good idea too... this would be a very easy option to add to the run-parts program.) o we want to allow cron to optimize away hourly disk accesses, as vixie-cron with a patch from debian already does. I've in the past showned that it's possible to code cron such that it doesn't require hourly disk accesses. (i.e., hold open a file descriptor for the /etc/cron.hourly directory; then every hour or so, do a fstat to check the modtime; this won't cause a disk access.) Yes, it requires making a code change. On the other hand, enough other changes need to be made to a Debian system (and I suspect most systems) before they will be laptop battery friendly anyway, so this argument doesn't seem to carry much weight, since at the moment, getting rid of cron.hourly won't help you much anyway. I'm running Debian/Woody on my laptop now, and.... * There's a crontab entry for exim which fires every 30 minutes, regardless of whether you have networking up (dumb, dumb, dumb, dumb). This causes the atime for the exim inode to be modified, but worse yet, the fact that the crontab entry specifies that the entry should run under the mail user, that means that there are multiple syslog messages from the pam message hitting /var/log/messages. The fundamental issue is that running the exim -q needs to run out of a special long-term running process, ala sendmail -bd, if you want to avoid waking the disk every time you want to try to flush the queue; merely running a non-root job out of crontab guarantees disk activity (because of the syslog writes), even if the program doesn't do anything else. * The syslogd is configured to create syslogd mark messages every 30 minutes (which of course is not synchronized with the above 30 minute exim queue flush), which in combination to the above causes the disks to spin up at least four times an hour. There may have been other laptop unfriendly daemons that were causing my disk to wake up, but at this point I gave up looking. Suffice it to say that there were a lot of problems.... o implementing anacron-like functionality produces unnecessary overhead if cron.hourly is in place (or the anacron-like functionality had to be switched off for cron.hourly resulting in inconsistent behaviour). What sort of "unnecessary" overhead are you referring to? Is this the need to spin up the disk to write anacron control entry file (i.e., /var/spool/anacron/cron.hourly)? Note though that anacron doesn't support any granularity finer than one day anyway, and so if a program were to put an entry into /etc/cron.d, they wouldn't have anacron functionality anyway --- and even if you put an entry into /etc/anacrontab (and the LSB doesn't guarantee the presence of anacron), you can't get one hour resolution anyway. So not having anacron functionality for cron.hourly doesn't seem like either a huge inconsisntency, given that there's absolutely no way to provide that sort of functionality anyway..... If people really don't want cron.hourly, we can remove it at least for LSB 1.0. But I would like to hear some other opinions about whether or not we should keep cron.hourly. What do folks think? - Ted