Bug#852314: stable release of debian now supports /run
Package: debian-policy Version: 3.9.8.0 Severity: minor Hi, policy 9.1.1 nr 8 and the upgrading checklist still mention that Packages must not assume that /run exists without a versioned dependency on initscript "until the stable release of Debian supports /run". This language will lure the unobserving package maintainer into adding this versioned dependency today when upgrading a long neglected package and working along the upgrading checklist. I therefore suggest removing the language from policy and the upgrading checklist. If you don't want to rewrite history regarding the upgrading checklist, please consider adding language like "packages can assume that /run exists without a dependency on initscripts" to the appropriate place in the upgrading checklist. Greetings Marc
Bug#804018: options to avoid service startup on package installation
On Wed, Jul 25, 2018 at 10:18:22AM +0100, Simon McVittie wrote: > policyrcd-script-zg2 is an adapter between the invoke-rc.d-defined API > (which says the policy-rc.d script must be in /usr/sbin) and what that > API should maybe have been all along (additionally looking for the script > in a configurable location, /usr/local/sbin, and /etc). And I still think that the adapter should be superfluous and the original API should be expanded. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#228692: User/group creation/removal in package maintainer scripts
On Tue, Jul 31, 2018 at 08:00:40PM -0700, Russ Allbery wrote: > As Guillem mentioned, I as a Debian user and system administrator would > dearly like to be able to configure Debian to delete created users when > the package is purged. I understand the reasons why we don't think this > is safe to do by default, but as an administrator, I care very, very > strongly about the property that installing a package and then purging it > should put the system back into the state it was in before the package was > first installed. I strongly dislike packages that leave "junk" behind. > > I realize that the cost of this is that I cannot use system users for > other purposes or give them ownership of files that aren't tracked by the > package manager or maintainer scripts, and I'm quite okay with this > tradeoff. > > I think Policy should say something like "created users and groups should > not be removed by default, but may be removed on purge if the local > administrator explicitly requests this, either for that package or as a > system-wide default." That could technically be achived by giving deluser a configuration file option modifying deluser --system's behavior, defaulting in not deleting the user. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#228692: User/group creation/removal in package maintainer scripts
On Tue, Jul 31, 2018 at 07:37:46PM +0100, Simon McVittie wrote: > dh-sysuser encapsulates maintainer script code into a single command, > although imperative rather than declarative. It uses useradd directly, > so it might be NIHing adduser(8). Augh! Seeing this saddens me deply. The history is that, one and a half decades ago, I came to the debhelper maintainer asking for a possibility to easily create system users from maintainer scripts without having to write actual code aside from a single call or a configuration file. I got a stern reply back that this is not debhelper's domain to solve. I went around spent a lot of time on adduser to reduce the code needed in maintainer scripts by handling a lot of Debianisms in adduser proper. And now, I not only see my original request implemented, negating the work I did on adduser, I also see debhelper NIHing my work, negiating it a second time. Day spoiled. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#228692: User/group creation/removal in package maintainer scripts
On Fri, Aug 03, 2018 at 09:44:35AM -0700, Russ Allbery wrote: > It might unspoil your day a bit to know that dh-sysuser is a standalone > package, not part of debhelper, so there's no evidence that the debhelper > maintainers have changed their mind on this without getting in touch with > you. It still saddens me that there is now more than one way to do it, without any visible trace of trying to improve the method that most packages use to create their users. What a waste of synergy. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#917995: debian-policy: drop section 1.6 Translations
On Wed, Jan 02, 2019 at 12:29:50PM +0900, Ansgar Burchardt wrote: > I hereby propose to drop section 1.6 Translations and the following > sentence: "When translations of this document into languages other > than English disagree with the English text, the English text takes > precedence." > > If it is wrongly translated, then the English text probably isn't > clear enough (otherwise the translation would have the same meaning) > and would need to be clarified anyway to avoid being ambigious. Even > if not, the same process can be used to clarify the meaning of > non-English versions. > > There should be no need to put one language over others. Please don't do this. While appreciating the effort the translators make to improve Debian's useability, the quality of the translations is sometimes bordering on sounding like satire. I cannot judge for any other languages than German though. Policy being a technical document, and most, if not all technical things in Debian require some proficiency in English, I'd instead propose dropping translations for Policy and other documents that are targeted at developers and package maintainers. It is important to have (good!) translations for users, the effort going into translating developer-only documents should better go in our user's direction. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#975250: clarify gathering together of copyright information
Package: debian-policy Version: 4.5.0.3 Severity: minor Hi, /usr/share/doc/debian-policy/copyright-format-1.0.txt.gz says |The Copyright field collects all relevant copyright notices for the files |of this paragraph. Not all copyright notices may apply to every individual |file, and years of publication for one copyright holder may be gathered |together. For example, if file A has: | | Copyright 2008 John Smith | Copyright 2009 Angela Watts | |and file B has: | | Copyright 2010 Angela Watts | |a single paragraph may still be used for both files. The Copyright field |for that paragraph would contain: | | Copyright 2008 John Smith | Copyright 2009, 2010 Angela Watts But what if file A says | Copyright 2008 John Smith | Copyright 2005-2015 Angela Watts and file B has: | Copyright 2010 Angela Watts Can this be gathered together to: | Copyright 2008 John Smith | Copyright 2005-2015 Angela Watts or does it have to be | Copyright 2008 John Smith | Copyright 2009, 2005-2015 Angela Watts ? Greetings Marc
Bug#975250: clarify gathering together of copyright information
On Thu, Nov 19, 2020 at 12:02:48PM -0700, Sean Whitton wrote: > The former. If you'd like to propose a patch making this clearer we > could get it applied. How about this: diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml index b8df359..71d7c1c 100644 --- a/copyright-format-1.0.xml +++ b/copyright-format-1.0.xml @@ -559,12 +559,21 @@ License: MPL-1.1 Copyright 2008 John Smith Copyright 2009 Angela Watts and file B has: -Copyright 2010 Angela Watts +Copyright 2005-2015 Angela Watts a single paragraph may still be used for both files. The Copyright field for that paragraph would contain: Copyright 2008 John Smith -Copyright 2009, 2010 Angela Watts +Copyright 2005-2015 Angela Watts + + + It is important that all copyright years mentioned in the + copyright notice are covered in the coalesced +Copyright field. It is ok to have years +covered that are not listed in the original notices. You are +allowed to coalesce copyright statements from multiple files +into a single copyright notice as long as all of the listed +authors and years are covered. The Copyright field may contain the original Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#975250: clarify gathering together of copyright information
On Fri, Nov 20, 2020 at 01:58:51PM -0700, Sean Whitton wrote: > On Fri 20 Nov 2020 at 03:23PM +01, Marc Haber wrote: > > > +Copyright field. It is ok to have years > > +covered that are not listed in the original notices. > > I don't think we can assume it is okay to do this. You can combine > 2009--2015 and 2020 into just 2009--2015, but I don't think we should > encourage combining 2009--2011 and 2013 into 2009--2013. That is what I assumed from the GNU wording quoted by Russ. What is the relevance of the years in leftpondian copyright law anyway? Over here, copyright expires a certain time after the copyright holder's death. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#975250: clarify gathering together of copyright information
On Sat, Nov 21, 2020 at 12:30:07PM -0800, Russ Allbery wrote: > Marc Haber writes: > > On Fri, Nov 20, 2020 at 01:58:51PM -0700, Sean Whitton wrote: > >> On Fri 20 Nov 2020 at 03:23PM +01, Marc Haber wrote: > > >> > +Copyright field. It is ok to have years > >> > +covered that are not listed in the original notices. > > >> I don't think we can assume it is okay to do this. You can combine > >> 2009--2015 and 2020 into just 2009--2015, but I don't think we should > >> encourage combining 2009--2011 and 2013 into 2009--2013. > > > That is what I assumed from the GNU wording quoted by Russ. > > The wording was used by upstream so the implication is that upstream is > asserting copyright changes in each of those years. If we broaden that > range, we're effectively adding copyright claims of additional years that > aren't necessarily true. I have a hard time imagining that it would ever > matter, but pedantically one cannot say 2009-2013 if no copyrightable > changes happened in 2012. ... and the new copyright format was devised to trigger pedantery. I must add that I absolutely hate the idea of spending more time with the copyright file than with actual packaging (happened to me twice in the last month alone), but technically that was alwas expected from us as DDs and if the project wants to have us doing busy work, then so be it. > The years are an annoying bit of pedantry. The short version is that US > copyright law requires a year in the notice, ok, that's a clear point. Here is a new suggestion: diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml index b8df359..12a84de 100644 --- a/copyright-format-1.0.xml +++ b/copyright-format-1.0.xml @@ -557,14 +557,24 @@ License: MPL-1.1 publication for one copyright holder may be gathered together. For example, if file A has: Copyright 2008 John Smith -Copyright 2009 Angela Watts +Copyright 2003,2009 Angela Watts and file B has: -Copyright 2010 Angela Watts +Copyright 2005-2015 Angela Watts a single paragraph may still be used for both files. The Copyright field for that paragraph would contain: Copyright 2008 John Smith -Copyright 2009, 2010 Angela Watts +Copyright 2003,2005-2015 Angela Watts + + + It is important that all copyright years mentioned in the + copyright notice are covered in the coalesced +Copyright field. It is ok to have years +covered that are not listed in the original notices. You are +allowed to coalesce copyright statements from multiple files +into a single copyright notice as long as all of the listed + authors and years are covered (and no not listed years are + accidentaly included). The Copyright field may contain the original Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#975250: clarify gathering together of copyright information
On Tue, Dec 01, 2020 at 08:07:34AM -0500, Sam Hartman wrote: > * Holder, you and I would prefer that you be able to collapse years. Basically, I want to reduce the horrible busy-work of creating and maintaining debian/copyright files to the barely acceptable minimum. I literally spent days in the last weeks just to collect copyright stuff that I would rather have spent with technical work. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Question on the use of "/nonexistent"
Hi, with my (sadly underused) adduser hat on, thank you very much for bringing this to public attention. and thank you all others who have replied in this thread. I don't have anything to add but my support for the way that has been unanimously lined out in this discussion. Jason, you have my "go" to do those changes, and if it would be my choice it'd be --homeless ;-) Otoh, --nonexistent-home would be more serious, but there is no much different to --home /nonexistent. Greetings Marc [nullquote doesnt mean disapproval of anything] -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Question on the use of "/nonexistent"
On Sun, Dec 19, 2021 at 12:59:25PM -0500, Jason Franklin wrote: > There are three improvements to make here: > > 1. Augment the documentation for "--no-create-home" to clarify intent. > 2. Implement the "--homeless" option. (This is tentative!) > 3. Add tests for these options! Yes! Rationale seconded. > For #3: I am currently trying to get up to speed with how to use > autopkgtest in adduser. I am reluctant to change anything other than > docs until I have a corresponding test for what I want to change. Once > I have a good workflow, I'll come back to this issue and make the > changes. I know that adduser is a Debian native package, but maybe we should go a little different way for testing. Doing autopkgtests is kind of expensive since it requires the package to be built and a test environment to be set up. Maybe it'd be a good idea to have a "normal testsuite" that maybe wraps useradd and userdel to simpler scripts that just log their command line and see in a test whether adduser issues the correct and expected calls to the lower-level tools. That way, running the test suite is easier and can be done from any source tree, not requiring root, and not breaking things. And then, in the autopkgtest, we could just call up the same testsuite, just "live" and checking whether the correct things happen on the system. But that's just a quick-shot idea that neither belongs in this bug report nor on debian-policy, lets move this discussion to adduser@p.d.o. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1006912: is it time to have account deletion in policy?
Package: debian-policy Version: 4.6.0.1 Severity: wishlist Hi! Currently, Policy does contain guidelines about system accounts being created on package installation. It is, however, more reluctant to give advice about accout deletion on package uninstall and/or purge. In Addition, the existing advice is somewhat hidden in chapter 9.2.2 documetning UID and GID classes. There is the requirement that a purged package vanishes completly. There seems to be consensus about this being not a good idea regarding account deletion since noone knows whether the local admin has given some files to the package account which would be left around unowned (and could even suddenly belong to a new account that was creatd with the same UID). There are way over 514 packages matching "adduser.*--system" on codesearch.debian.net, but just 125 packages containing "deluser.*--system". I didn't check in all details whether all of those matches are in maintainer scripts, but I think that this gives a rough overview how many packages do not delete their account at the current time. How about putting advice like this in policy: Suggestion 1: Create a dedicated chapter (which would ideally be placed between the current chapters 9.2.1. Introduction and 9.2.2. UID and GID classes) named "dynamically allocated system users or groups for packages" with the following contents: - packages can create users and groups on installation - usernames should be chosen wisely, allowing to deduce the related package from the name, and prefixed with an underscore - adduser --system is the preferred method to create package account, it takes responsibility of being policy compliant. Other packages doing this job might exist (dh-sysuser, for example). Suggestion 2a: Document that a package should not delete its user on uninstallation and/or purge. This reflects current practice of most packages but might need changes in some packages that currently delete their user. Those packages are the reason that this policy item should not be introduced as a MUST. Suggestion 2b: Document that a package may lock its user on uninstall, but leave it on the system on purge. That way, a leftover account could not be used as an attack vector and just blocks the uid/gid and the name. On reinstallation of a package, the existing, locked account would just be unlocked. This would be a new behavior that could be worth documenting in Policy. Should the policy editors indicate that this might be an option, adduser would be willing to implement a deluser --lock --system option that would lock a named account if its uid is in the appropriate range for system accounts, and adduser --system would not error out if the account already exists and would just remove the lock. Thus implementing this option in a package would just mean to add the appropriat deluser call to postrm uninstall while postinst can remain unchanged. transparency advice: I am on the adduser maintainer team and have the longest track history of caring for adduser of all active team members. I am willing to suggest wording, but I am not a policy expert and wording would probably be better if an experienced policy editor would write the appropriate language. How would a new chapter be inserted in Policy without destroying existing references to chapter numbers? I would like to hear your opinion on that. Thanks for considering. Greetings Marc
Bug#1006976: what about dynamically allocated groups?
Package: debian-policy Version: 4.6.0.1 Severity: minor Hi, 9.2.2 distinguishes between 100-999: Dynamically allocated system users and groups. and 1000-5: Dynamically allocated user accounts. This wording is a bit confusing, but this is probably caused by the ambiguity between users and accounts. I am also astonished that the 1000-5 GIDs are not mentioned in policy, or is a group also a very special kind of account? Probably yes, at least that's what groupadd's docs say. So the easiest way to solve this and to be consistent with passwd/shadow would be: How about: 100-999: Dynamically allocated system user and system group accounts. Packages which need a user or group, but can have them and their UID/GIDs allocated dynamically and differently on each system, should use "adduser --system" or "addgroup --system" to create them as needed. These tools will check for the existence of the user or group, and if necessary choose an unused id based on the ranges specified in "adduser.conf". 1000-5: Dynamically allocated user and group accounts. By default "adduser" and "addgroup" will choose UIDs and GIDs for user and group accounts in this range, though "adduser.conf" may be used to modify this behavior. Greetings Marc
Bug#1006912: is it time to have account deletion in policy?
On Wed, Mar 09, 2022 at 11:07:54PM +0500, Andrey Rahmatullin wrote: > Previous, still open, bug from 2004: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228692 thanks for pointing this out. I have made some notes (both for adduser and for policy) from that bug. Adduser development has regaind momentum, so I see it possible that we get the necessary adduser changes in Debian before bookworm so that we can, as a second step, amend policy and debhelper. Please expect me to come up with suggested wording for policy that referes to some adduser features that do not yet exist, but with my adduser hat on, I will do my best to have those features implemented before the suggested wording can be included in Policy. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1006912: is it time to have account deletion in policy?
+Locking package UIDs on package deinstallation +~~ + +A package should lock its UIDs on uninstallation, but leave the UIDs and GIDs +in place on purge. The local administration might have used the UIDs and GIDs +for files that the package doesn't know of; removing the account would leave +those files ownerless and may expose information to unrelated parties in the +case that the numeric UIDs or GIDs get re-used at some later time. + +The ``deluser`` tool offers helpful functionality that allows a postrm script +to follow policy while giving the local administrator the possibility to +override policy so that package-related UIDs and GIDs are actually removed +from the system on purge. See the deluser manual package for details. + +// this is not yet implemented in deluser .. _s9.2.2: -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1006912: is it time to have account deletion in policy?
On Sat, Mar 12, 2022 at 11:58:31AM +, Holger Levsen wrote: > On Fri, Mar 11, 2022 at 08:15:37PM +0100, Marc Haber wrote: > > This is my patch. > > I like your patch. :) I just have one comment: > > > +``Dynamic local`` allocated ids should by default be arranged in some > > +sensible order, but the behavior should be configurable. > > unpredictable or non-deterministic allocation of such ids is a cause of non- > reproducibiliy for Debian images and installations, so us reproducible folks > would like to see "sensible" to be expanded to take reproducible builds into > account. So we should go (in Policy) more towards "dynamic global UIDs and GIDs which may post additional load towards the base-passwd maintainers? Or would it be enough for reproducible images if adduser would finally implement #243929, making it possible to pre-determine UIDs before an image is built? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1006912: is it time to have account deletion in policy?
On Sat, Mar 12, 2022 at 01:00:44PM +, Holger Levsen wrote: > Roland Clobus has put a lot of work & thoughts into reproducible images, so > I've > added him to cc: now, so he can comment on this aspect of #1006912. Policy editors, I think we can now choose between taking care of the needs of reproducible images right with this policy change or do de-scope this temporarily until we have settled on the new wording (which also includes some definitions) and then handle this in a second change. I think the second change also needs the base-passwd people in the loop. How would you prefer to do this? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1006912: is it time to have account deletion in policy?
On Sun, Mar 13, 2022 at 03:03:34PM -0700, Sean Whitton wrote: > On Sat 12 Mar 2022 at 03:01PM +01, Marc Haber wrote: > > On Sat, Mar 12, 2022 at 01:00:44PM +, Holger Levsen wrote: > >> Roland Clobus has put a lot of work & thoughts into reproducible images, > >> so I've > >> added him to cc: now, so he can comment on this aspect of #1006912. > > > > Policy editors, I think we can now choose between taking care of the > > needs of reproducible images right with this policy change or do > > de-scope this temporarily until we have settled on the new wording > > (which also includes some definitions) and then handle this in a second > > change. I think the second change also needs the base-passwd people in > > the loop. > > The latter, please, assuming I'm not misunderstanding and the first > change makes things worse on the reproducibility front. I am not a native speaker, but in my understanding my proposed wording does not change the way we're creating UIDs right now, just clarified terminology and explicitly writes down how things are done now, and Roland confirmed that the current image process doesn't care about numerican UIDs at all since they already make sure that package installation happens in a pre-defined order. That being said, an upcoming adduser change will allow local administrators (including image creators) to pre-define the numerical UIDs before the actual account gets created. This, however, does not influence the order of accounts listed in /etc/passwd, for this to be reproducible, the passwd / shadow package should make sure that their user database files are sorted. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1015784: source-only upload requirement not documented
Package: developers-reference Version: 12.5 Severity: normal Hi, for a few years now, the Debian archive wants to see source-only uploads. This is not documented in the Developer's Reference and also now in the New Maintainer's Guide. It should be there. Also, it should be documented that the first upload of a new package to debian MUST be a source+binary upload. Arch all packages need another source-only upload after being accepted into the archive to be allowed to migrate to testing. I THINK that arch any packages get an automatic binNMU to avoid that. Greetings Marc
Re: Bug#39830: [PROPOSED]: get rid of undocumented(7) symlinks
On 23 Jun 1999 01:57:45 -0500, you wrote: >The bug reports are not the important part. Lack of a man page > is grounds for a bug report, the man page is to prevent gazillions of > identical reports. In that case, the link to undocumented(7) should only be allowed if there actually is a bug in existance. Greetings Marc -- -- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
/var/state?
Hi!
/var/state isn't in the fsstnd, yet it exists on Debian slink. Is
there a text available that states what belongs into /var/state vs.
/var/lib ("application state information")?
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: /var/state?
On Sun, 27 Jun 1999 15:28:55 -0500, you wrote:
>On 27-Jun-99, 10:00 (CDT), Marc Haber <[EMAIL PROTECTED]> wrote:
>> /var/state isn't in the fsstnd, yet it exists on Debian slink. Is
>> there a text available that states what belongs into /var/state vs.
>> /var/lib ("application state information")?
>
>/var/state was originally part of the FHS (v 2.0?). There were lots
>of objections, do the difficulting many packages would have in moving
>existing state info from /var/lib. The most recent drafts for FHS 2.1
>have removed /var/state, but changed the specification of /var/lib to
>be more consistent with the actual usage.
So using /var/state is actually discouraged?
Greetings
Marc
--
------ !! No courtesy copies, please !! -
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: /var/state?
On Sun, 27 Jun 1999 20:04:19 +0200, you wrote:
>Marc Haber schrieb am Sonntag, den 27. Juni 1999:
>> /var/state isn't in the fsstnd, yet it exists on Debian slink. Is
>> there a text available that states what belongs into /var/state vs.
>> /var/lib ("application state information")?
>
>/var/state was introduced in FHS 2.0:
>But FHS 2.1-pre-02 stepped back and places all the files, which 2.0
>placed in /var/state, in /var/lib again.
:-(
>So I fear, that we have to change the packages using /var/state again
>to use /var/lib.
:-(
>PS: I personally prefer /var/state, but that's a different question.
I couldn't agree more. Having information that is clearly non-library
in a lib subdirectory is ugly and misleading.
Where am I to put configuration information that is invalidated by a
system boot? A RAM disk would be fine, but that would be overkill.
Greetings
Marc
--
------ !! No courtesy copies, please !! -
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: /var/state?
On Tue, 29 Jun 1999 21:55:49 -0600 (MDT), you wrote: >Personally I think /var/state is a much more accurate name, I have to agree on that matter. I'd expect executeable code in /var/lib. But heck, some standards have to exist. Greetings Marc -- -- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Bug#621833: System users: removing them
On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote: > 2) Reinstallation. > >I'm currently using this logic (in postinst) > > # Create dedicated sbuild user > if ! getent passwd sbuild > /dev/null; then > adduser --system --quiet --home /var/lib/sbuild --no-create-home \ > --shell /bin/bash --ingroup sbuild --gecos "Debian source builder" > sbuild > fi Cheking for the account already being present in postinst should not be necessary. Adduser is designed to do the right thing without additional logic in maintainer scripts. If it doesn't, please file a bug. If people find it desireable to automatically unlock an existing account on adduser --system , this could easily be implemented in adduser, doing the right thing to locked accounts. If that may be necessary, please file a bug against adduser. > I do agree that a --local option would be a valuable and useful > addition to the adduser and deluser etc. tools, even if currently > a no-op. However, due to the above I don't think that adding > special-case user locking to deluser is the correct course of action. What should the --local option do? If you want adduser to grow this option, please file a bug. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110530084313.gb27...@torres.zugschlus.de
Bug#621833: System users: removing them
On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote: > We could add special behaviour to adduser to unlock the account > if it already exists when run in the postinst. Yes. > However, most postinsts wrap the call to adduser with a check for > whether the account already exists, Which would be a bug in the maintainer scripts. > I dislike the fact that the behaviour of adduser and deluser would, > in effect, /not/ add or delete users as intended, which is rather > counter-intuitive. adduser --system is designed (and, IIRC, documented) to have the effect of "after the call to adduser --system, the account will exist and is useable. The only case when adduser --system really errors out is when the account already exists but is not a system account." > Providing that we have consensus on a recommended strategy for > locking and unlocking accounts which can go into policy, I think all > we need are examples for how maintainer scripts are expected to > handle account creation and locking/unlocking. The would be rather easy. Account creation/unlocking would happen with an unwrapped call to adduser --system, account locking with a call to the appropriate back-end command, or we could add an lockuser command to the adduser package. I think, the latter would be preferable since we would then be able to add sugar to the locking process. A wishlist bug against adduser is in order. Greetings Marc, with a rather worn and dusty adduser hat on -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110530084708.gc27...@torres.zugschlus.de
Bug#621833: locking system users on package removal
On Sat, 30 Jun 2012 14:36:47 +0100, Roger Leigh wrote: >On Sat, Jun 30, 2012 at 02:12:45PM +0100, Simon McVittie wrote: >> [in the preinst] >> > -usermod -U -e '' quake-server >> > +if [ -f /etc/shadow ]; then >> > + usermod -U -e '' quake-server >> > +else >> > + usermod -U quake-server >> > +fi >> [in the postrm] >> > # Lock account on purge >> > -usermod -L -e 1 quake-server >> > +if [ -f /etc/shadow ]; then >> > +usermod -L -e 1 quake-server >> > +else >> > +usermod -L quake-server >> > +fi > >It looks sane to me. Having a dh_ command or some other dpkg >maintscript helper shell function to do this automatically would >IMO be a very nice improvement. Given the amount of code lines that were spent in adduser to allow its transparent usage in maintainer scripts, I would prefer having that code in adduser. with adduser --lock locking an account and adduser --system unlocking a locked user that is present but locked. Having debhelper code for that is wrong since it means rebuilding packages to fix bugs in that code. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1skzbj-0002hw...@swivel.zugschlus.de
Bug#621833: System users: removing them
On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote: >I'm currently using this logic (in postinst) > > # Create dedicated sbuild user > if ! getent passwd sbuild > /dev/null; then > adduser --system --quiet --home /var/lib/sbuild --no-create-home \ > --shell /bin/bash --ingroup sbuild --gecos "Debian source builder" > sbuild > fi > > However, consider that if the account is locked, the user already > exists and no unlocking will occur, leaving the reinstalled > package broken. This logic is common to many packages. That's a bug in a lot of packages, yes. adduser has been designed to allow adduser --system to be called without that logic: If called with one non-option argument and the --system option, adduser will add a system user. If a user with the same name already exists in the system uid range (or, if the uid is specified, if a user with that uid already exists), adduser will exit with a warning. This warning can be suppressed by adding "--quiet". So, just remove the extra getent passwd check and you should be fine. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701095311.ga7...@torres.zugschlus.de
Bug#621833: System users: removing them
On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote: > We could add special behaviour to adduser to unlock the account > if it already exists when run in the postinst. Yes, that would be the way to go for adduser --system > However, most postinsts wrap the call to adduser with a check for > whether the account already exists, so it would not be called > without an update to every preinst employing this strategy. Yes, packages having used that approached are buggy in the first place. > It would also alter the existing behaviour of adduser, which is to > return nonzero if the user already exists, which could cause > breakage. NACK, adduser --system does return zero if the user already exists and its parameters are sufficiently similiar to the parameters requested by the maintainer script. > I dislike the fact that the behaviour of adduser and deluser would, > in effect, /not/ add or delete users as intended, which is rather > counter-intuitive. Providing that we have consensus on a recommended > strategy for locking and unlocking accounts which can go into policy, > I think all we need are examples for how maintainer scripts are > expected to handle account creation and locking/unlocking. NACK, don't put the same logic into a hundred maintainer scripts where they'll have two hundred different bugs. Put the logic into a central place where bugs can be handled centrally. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701095539.gb7...@torres.zugschlus.de
Bug#621833: What about userdel?
On Sun, May 29, 2011 at 11:52:40AM +0100, Nicholas Bamber wrote: > I am managing a package that does 'userdel' in a purge. Don't do that, use deluser, if you insist. And even that is dangerous. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701095655.gc7...@torres.zugschlus.de
Bug#621833: System user handling in packages: status of discussion
On Fri, Jun 10, 2011 at 10:12:20AM +0100, Lars Wirzenius wrote: > * To create an user, a maintainer script should call > "adduser --system foo". It is not necessary to wrap this in > a check for whether the user exists. It would be a bug to do so. Add --quiet to the adduser call if you don't want to show the resulting warning to your users, but I'd recommend to leave the warning active. > * When the package is removed, the user should be locked: > "lockuser foo". > * lockuser is a still-hypothetical tool, which needs to be added > to the adduser package. It is a wrapper around "usermod -L -e 1 foo". > * Similarly, adduser needs to be changed to unlock: > "usermod -U -e '' foo". Why not extending deluser to not delete the user if it is a system account? > Unclear to me are the following two points: > > * Should packages also remove the contents of the system account's > home directory? No, the local admin might have put important additional data in there. It may be an idea to remove all files that the _package_ has put there, but that would be a _significant_ burden IMO. > Should this be done upon package remove or purge? Purge, of course. When you remove and reinstall, you should be exactly where you were before. > * Is there consensus that adduser should get a --local option, > and if so, what should its semantics be, and should packages > start using it now? Or can this wait until there's an actual > need for --local, so that the precise semantics can be defined? > There's a fairly few packages that create users, so we should > be able to deal with them fairly easily later. Actually --system was meant for that. Greetings Marc, who has for quite some time taken care of adduser but has lost touch to the package recently -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701100025.gd7...@torres.zugschlus.de
Bug#621833: System user handling in packages: status of discussion
On Fri, Jun 10, 2011 at 11:00:14AM +0100, Roger Leigh wrote: > Would "lockuser" need to be in the adduser package? Given that > adduser is only priority:important, it's not guaranteed to be present > when postrm is run, so the operation could fail. Maybe passwd is a > better place for it, given that it contains useradd etc., and is > priority:required. adduser should be elevated to priority:required then. adduser contains all Debian logic for account handling, while passwd doesn't. adduser is the logical place for Debianisms. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701100129.ge7...@torres.zugschlus.de
Bug#679751: please clarify package account and home directory location in policy
Package: debian-policy Severity: normal Hi, many packages have to create system accounts on installation. Unfortunately, Debian policy is not quite clear on how to handle these. On the other hand, Debian QA is keen on addressing issues in account handling, which frequently leads to discussions about how to handle things like that, resulting in maintainer time being wasted to make unncessary changes to a package that could have been done "right" in the first place. #621833 has a lengthy discussion about what happens to an account on package removal / purge, but other things are stil open and unaddressed by Policy. I won't address the old user name (package versus Dpackage versus Debian-package versus debian-package) issue here since the discussions about that have died down in the last years and one gets away pretty well with Debian-package. But I need to address the "where to put a users' home dir" issue. Recently, QA has filed quite some bugs about system users' home dirs not being allowed in /home, (mis)interpreting the FHS (chapter /home) at this point, saying /home : User home directories (optional) /home is a fairly standard concept, but it is clearly a site-specific filesystem. [9] The setup will differ from host to host. Therefore, no program should rely on this location. Unfortunately, Policy is not clear on where a system accounts' "home directory" is to be placed. Thus, a maintainer trying to fix the "bug" that a home directory was placed *gasp* in /home is risking to do it wrong again when choosing between /etc/package(/home) and /var/(lib|cache|spool)/package(/home). In quite a few packages, the system user's "home" directory might accumulate dotfiles and/or ssh (keys|known_hosts) files, so this decision is not quite easy to take. I would love to have policy clearly say where a system users' home directory is to be placed. This saves a lot of maintainer time and grief with QA actions. If this were clearly laid out in Policy, QA would also be saved from discussions with grumpy maintainers like me, since they would have a clear reference to cite without having to bend FHS. Sorry, but I cannot suggest Policy language since I don't know how do to things right and I still believe that /home is a valid place for home directories. Greetings Marc -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701102459.5134.16280.report...@salida.zugschlus.de
Bug#621833: What about userdel?
On Sun, Jul 01, 2012 at 11:15:18AM +0100, Nicholas Bamber wrote: > I had the feeling things were going to be clarified so > I was waiting on that clarification. That is of course acceptable. Don't break things until Policy forces you to do so ,-) Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701102552.gc25...@torres.zugschlus.de
Bug#621833: System users: removing them
On Sun, Jul 01, 2012 at 12:35:26PM -0700, Steve Langasek wrote: > On Sun, Jul 01, 2012 at 11:55:39AM +0200, Marc Haber wrote: > > > It would also alter the existing behaviour of adduser, which is to > > > return nonzero if the user already exists, which could cause > > > breakage. > > > NACK, adduser --system does return zero if the user already exists and > > its parameters are sufficiently similiar to the parameters requested > > by the maintainer script. > > How is "sufficiently similar" defined, and where is it documented? It's not > in policy, and I don't see anything in the adduser manpage that explains > this. Add a system user If called with one non-option argument and the --system option, adduser will add a system user. If a user with the same name already exists in the system uid range (or, if the uid is specified, if a user with that uid already exists), adduser will exit with a warnâ ing. This warning can be suppressed by adding "--quiet". If that's not enough, a bug report against adduser is in order. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702074806.ga31...@torres.zugschlus.de
Bug#621833: System user handling in packages: status of discussion
On Sun, Jul 01, 2012 at 12:42:23PM -0700, Steve Langasek wrote: > On Sun, Jul 01, 2012 at 12:00:25PM +0200, Marc Haber wrote: > > On Fri, Jun 10, 2011 at 10:12:20AM +0100, Lars Wirzenius wrote: > > > * When the package is removed, the user should be locked: > > > "lockuser foo". > > > * lockuser is a still-hypothetical tool, which needs to be added > > > to the adduser package. It is a wrapper around "usermod -L -e 1 foo". > > > * Similarly, adduser needs to be changed to unlock: > > > "usermod -U -e '' foo". > > > Why not extending deluser to not delete the user if it is a system > > account? > > Because that's contrary to the obvious meaning of 'deluser' and will be > confusing to maintainers, if it doesn't actually result in the user being > deleted. It's much better to have an interface that does what it says. That would mean changing probably thousands of packages. > > No, the local admin might have put important additional data in there. > > It may be an idea to remove all files that the _package_ has put > > there, but that would be a _significant_ burden IMO. > > This should be configurable by the package maintainer using a > --remove-home flag. In the general case, admins should not use > per-package directories under /var/lib as a dumping ground for > arbitrary files and then expect these files to be retained when the > package is purged. If that behavior is documented (in Policy?), I am fine with zapping user data. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702075035.gb31...@torres.zugschlus.de
Bug#679751: please clarify package account and home directory location in policy
On Sun, Jul 01, 2012 at 10:08:40AM -0700, Russ Allbery wrote: > Marc Haber writes: > > In quite a few packages, the system user's "home" directory might > > accumulate dotfiles and/or ssh (keys|known_hosts) files, so this > > decision is not quite easy to take. > > If those files are intended to be persistant, then either /etc/package or > /var/lib/package are pretty much your only options. The semantics of the > other locations you mention don't allow for those sorts of files. /var/lib/package cannot be used as ssh keys can be considered configuration data which is explicitly forbidden for /var/lib. > > Sorry, but I cannot suggest Policy language since I don't know how do to > > things right and I still believe that /home is a valid place for home > > directories. > > /home is definitely unacceptable for the reasons stated in the FHS, Please clarify this in policy. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702080933.ge31...@torres.zugschlus.de
Bug#621833: System user handling in packages: status of discussion
On Mon, Jul 02, 2012 at 09:12:00AM +0100, Lars Wirzenius wrote: > Back in 2011-04-04 (see first mail in the bug report you're cc'ing to) > I did some greps, and found 103 packages that mention deluser in their > maintainer scripts. How did you come to the conclusion of "thousands > of packages"? If you're just guessing wildly, please stop: Debian > development is hard enough, let's try to stick to facts and when they're > not available, investigate rather than assume. I was extrapolating from my own packages to Debian proper, which was probably skewed. I apologize. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702104759.gj31...@torres.zugschlus.de
Bug#679751: please clarify package account and home directory location in policy
On Mon, Jul 02, 2012 at 09:50:37AM -0700, Russ Allbery wrote: > I'm not sure that I understand the use case. I've never needed to create > an authorized_keys file for a system account created by a package. Maybe > you could explain more about what you're doing that makes this a > reasonable thing to do? The package has a collector and a presenter component and uses rsync-over-ssh to transfer collected data to the presenter. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702210522.gc31...@torres.zugschlus.de
Bug#679751: please clarify package account and home directory location in policy
On Mon, Jul 02, 2012 at 02:29:53PM -0700, Russ Allbery wrote: > Marc Haber writes: > > On Mon, Jul 02, 2012 at 09:50:37AM -0700, Russ Allbery wrote: > > >> I'm not sure that I understand the use case. I've never needed to > >> create an authorized_keys file for a system account created by a > >> package. Maybe you could explain more about what you're doing that > >> makes this a reasonable thing to do? > > > The package has a collector and a presenter component and uses > > rsync-over-ssh to transfer collected data to the presenter. > > Ah, okay. For that use case, the only thing that you would care about the > user home directory containing is the authorized_keys file, correct? known_hosts and the key itself. > In this case, you could either put the home directory in /etc, or put the > home directory in /var/lib with a symlink from .ssh/authorized_keys to > /etc. I would tend to do the latter since you can then use more > reasonable file names in /etc, such as /etc//authorized_keys. > > I confirmed that sshd is perfectly happy with a /var/lib/ > directory with an .ssh subdirectory owned by root and a root-owned symlink > from authorized_keys to a file /etc. I would pre-create the file in /etc > with a comment saying what it's for. Will try that *sigh* Thanks for your comments. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120703075041.gi31...@torres.zugschlus.de
Bug#679751: please clarify package account and home directory location in policy
On Tue, Jul 03, 2012 at 10:04:45AM -0700, Russ Allbery wrote: > Marc Haber writes: > > On Mon, Jul 02, 2012 at 02:29:53PM -0700, Russ Allbery wrote: > > >> Ah, okay. For that use case, the only thing that you would care about the > >> user home directory containing is the authorized_keys file, correct? > > > known_hosts and the key itself. > > Oh, right, for the client. Yes, yes. > > Well, personally I would not consider either the client's key or the > known_hosts file to be configuration files. Why not generate the client's > key automatically with ssh-keygen on client package installation, and then > let it discover the known_hosts configuration via some mechanism, leaving > both of those in /var/lib? That would satisfy the requirement that the > admin not have to touch things in /var/lib to make the package work, and > would also simplify setup (since then building the authorized_keys file is > just a matter of catting together the id_rsa.pub files). The package itself caters only for presenter and collector on the same machine, which is done to give a working setup after installation. The package is not likely to be used in this configuration in any productive environment. ssh is one of the variants that is offered to the admin as optional, local configuration. So she needs to manually touch ssh stuff. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120703183934.gb14...@torres.zugschlus.de
Bug#679751: please clarify package account and home directory location in policy
On Tue, Jul 03, 2012 at 10:52:26AM -0700, Russ Allbery wrote: > I think it's perfectly acceptable to have an admin drop data into a > /var/lib directory for non-default configurations of packages. Is this documented in policy? Greetings Marc, really reluctant to spend days to change a package in a way that might not be policy compliant and might cause the next RC bug to be slapped upon me -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120703184132.gc14...@torres.zugschlus.de
Bug#804018: dpkg: provide options to avoid service startup on package installation
Hi, just talking into the wild here. On Mon, Nov 09, 2015 at 06:07:24PM +0100, Evgeni Golov wrote: > That said, back to the original topic. I agree with Patrick that we need > a flexble way to tell "the system" whether we want to start a specific > service on installation or not. The mentioned policy-rc.d system may > help here, but is not in the current state of documentation and > implementation. I agree that policy-rc.d would be the right place. The policyrcd-script-zg2 package shows how this could be addressed. My script just looks into /usr/local/sbin/policy-rc.d or /etc/policy-rc.d and executes the files if they exist. This just moves the place where the local admin places his local script into a directory which is in her local domain, a rather trivial task. For the task at hand, I would think that it would probably be a good idea to have /etc/policy-rc.d as a directory which holds files called like services. For example, to stop apache from being started on package installation and upgrades, one would drop a file into /etc/policy-rc.d/apache. That file could either contain configuration data like a single line of "allowed", "undefined", "unknown", "forbidden", "error" (see other values in /usr/share/doc/sysv-rc/README.policy-rc.d.gz) or have there a simple shellscript with the appropriate exit code. That way would allow a per-service configuration of process start behavior. The script handling the /etc/policy-rc.d/* file/scripts could even be in a package (and I could finally retire the rather trivial policyrcd-script-zg2). Disclaimer: I do not know whether the new nice systemd world still honors invoke-rc.d mechanisms. The scripts and documentation originate from sysv-rc which is at least still present on my systemd-pid1-sid systems, so there is hope. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#804018: dpkg: provide options to avoid service startup on package installation
On Thu, Nov 19, 2015 at 12:35:02PM +, Simon McVittie wrote: > invoke-rc.d is run by the maintainer scripts of packages with a sysvinit > script (regardless of whether they have a corresponding systemd unit or > not), and by various other Debianisms like logrotate hooks. It runs > policy-rc.d. Will this also work if a package does not come with a sysvinit init script, or the sysvinit init script is overridden by a native systemd unit? > deb-systemd-invoke is run by the maintainer scripts of packages with a > systemd unit and no corresponding sysvinit script. It does not run > invoke-rc.d - I assume there's a technical reason why it can't - but it > does run policy-rc.d itself. > > systemd also lets you "mask" a unit, which prevents it from being > started at all, whether the start attempt is done manually, during boot > or from a maintainer script. Can a unit be masked before the corresponding package is installed? That being said, this bug is only about preventing a service from being started when the package is installed or updated. keepalived etc do need to be able to start the service manually, which is also prevented by systemd's mask mechanism. > Normal boot and shutdown do not use policy-rc.d, the same as in sysvinit. I didn't think about that. One would need a mechanism to prevent this as well since one probably doesn't want a keepalived-managed service to be started on system boot. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Servers going online automatically?
On Sat, Dec 05, 2015 at 08:27:56PM +, Vesa Paatero wrote: > Now, I am not expecting to get that policy changed just like that but > would it be a good idea to mandate some documentation, perhaps a > notification to the package description, for those packages that > expose such an interface to the world without user interaction? How many of our _DEFAULTS_ do you expect us to document in all package descriptions affected by that _DEFAULT_? That being said, I'd like to plug http://blog.zugschlus.de/archives/974-Debians-Policy-rc.d-infrastructure-explained.html once more. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Servers going online automatically?
On Tue, Dec 08, 2015 at 08:44:22PM +, Vesa Paatero wrote: > On Sunday, December 6, 2015 7:43 PM, Marc Haber > wrote: > > On Sat, Dec 05, 2015 at 08:27:56PM +, Vesa Paatero wrote: > > > > > Now, I am not expecting to get that policy changed just like that but > > > would it be a good idea to mandate some documentation, perhaps a > > > notification to the package description, for those packages that > > > expose such an interface to the world without user interaction?> > > > > How many of our _DEFAULTS_ do you expect us to document in all package > > descriptions affected by that _DEFAULT_? > > > I understand. But maybe documenting such "affecting defaults" could > make sense if they were expressed as flags of some sort so that they > wouldn't make the descriptions too long. For example, text "[SERVER]" > at the bottom of the description could indicate that package > establishes a server on your computer -- and then all those bracketed > flags in use would be explained on some web page. Don't we already have a debtag to do so? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Task list for a policy release
On Sat, Dec 01, 2007 at 04:52:16PM -0200, Felipe Augusto van de Wiel (faw) wrote: > Considering the chance of rewriting the document and using > UTF-8, can you consider the idea to add support for translations in > the build process and repository layout while doing the rewriting? Debian policy is an internal normative document, specifying technical aspects of the Debian OS. Please refrain from adding ambiguities by translating this document to other languages than English. The audience of this document is required to speak sufficient english anyway, so there is no point in translating. Greetings Marc, not a native speaker of English -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: About Debian Policy translations (was: Re: Task list for a policy release)
On Sat, Dec 01, 2007 at 08:53:19PM -0200, Felipe Augusto van de Wiel (faw) wrote: > On 01-12-2007 19:53, Marc Haber wrote: > > On Sat, Dec 01, 2007 at 04:52:16PM -0200, Felipe Augusto van de Wiel (faw) > > wrote: > >>Considering the chance of rewriting the document and using > >> UTF-8, can you consider the idea to add support for translations in > >> the build process and repository layout while doing the rewriting? > > > > Debian policy is an internal normative document, specifying technical > > aspects of the Debian OS. Please refrain from adding ambiguities by > > translating this document to other languages than English. > > You should be more confident on your fellow translators. :) After seeing the "quality" of Debian's German translation (which is the only one I can really judge since it's the only language that I have sufficiently mastered), I do not have _any_ confidence in translations any more. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: About Debian Policy translations
On Sun, Dec 02, 2007 at 11:45:48PM -0200, Felipe Augusto van de Wiel (faw) wrote: > I'm really sorry to learn that. You should volunteer to > help them improve it. I tried that. They told me that their method of work is ok, that my translations are horrible denglish, and that "Sicherheits-Gutachten" would be an appropriate translation for "security advisory". I stopped wasting my time. Greetings Marc, who prefers to volunteer for things that are appreciated. -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)
On Sat, Jul 05, 2008 at 10:58:35AM +0200, Raphael Hertzog wrote: > THanks, I could come up with a transition plan myself if needed. But > compare your suggestions with: "someone goes over all init scripts, file > bugs and in lenny+1 we're done". That'll cause tremendous pain for backporters. I'm opposed. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#75955: Section 4.2.14 has obsolete information
Package: packaging-manual Version: 3.1.1.1 Severity: normal Packaging Manual 4.2.14 treats stable, unstable, contrib and non-free as "Distributions", which is no longer true for contrib and non-free. sources.list(5) calls main, contrib and non-free "components", so I'd like to see that word in the packaging manual as well. Greetings Marc -- System Information Debian Release: 2.2 Architecture: i386 Kernel: Linux paola 2.2.17 #1 Tue Sep 5 10:36:11 CEST 2000 i586
Bug#83487: please add HTML version of FHS
Package: debian-policy Version: 3.1.1.1 Severity: wishlist The package includes the FHS in ps, dvi and txt. Please consider adding the HTML version as well. Thanks. Greetings Marc -- System Information Debian Release: 2.2 Architecture: i386 Kernel: Linux paola 2.2.18 #1 Tue Dec 12 11:54:38 CET 2000 i586
Should we allow packages to depend on packages with lower priority values?
Policy 2.5 says that packages must not depend on packages with lower priority values. From what I tried to research, that rule is meant to allow CD builders to build "Debian foo standard" CDs containing required, important and standard packages, guaranteed that all dependencies are satisfied just from choosing from the Priority. This must be residue from the times when CD building tools didn't follow dependency chains. Today, it is trivial to build dependency-complete "Debian standard" CDs by including required, important and standard packages and following down the dependency chain. apt-get is a tool that can solve this, and at least the old CD building tools used apt-get to resolve the dependencies. This has been the case at least since slink when I joined the Debian user community. This being said, I'd like to point out a problem that this policy requirement poses. Let A and B both be packages that provide virtual package C. A is the default C in Debian, and is therefore Priority: important. A depends on E and F, which must be Priority: important as well, as required by current Policy. Now let's look at a system where the local administrator has decided to use B instead of A. Since E and F are Priority: important, dselect happily proceeds to install E and F on the system, even if they are not needed since the system in question uses B instead of A. To put it short: The last paragraph of Policy 2.5 is cruft that is no longer needed any more. It should be removed from Policy since we have had CD builder packages available that can follow dependency chains. I don't see other reasons behind the requirement, but am of course open to arguments. Did I overlook something? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Should we allow packages to depend on packages with lower priority values?
On Mon, 8 Dec 2003 17:21:28 +0100 (CET), Santiago Vila <[EMAIL PROTECTED]> wrote: >On Mon, 8 Dec 2003, Marc Haber wrote: >> Policy 2.5 says that packages must not depend on packages with lower >> priority values. From what I tried to research, that rule is meant to >> allow CD builders to build "Debian foo standard" CDs containing >> required, important and standard packages, guaranteed that all >> dependencies are satisfied just from choosing from the Priority. > >Not only that, combined with the rule saying "packages which conflicts >with optional or higher should be extra", people should be able to >forget completely about extra packages when choosing packages without >having unmet dependencies. Why should they be able to forget about extra packages. I don't see any place where this matters, except CD creation. >> Now let's look at a system where the local administrator has decided >> to use B instead of A. Since E and F are Priority: important, dselect >> happily proceeds to install E and F on the system, even if they are >> not needed since the system in question uses B instead of A. > >So you want postfix but not the dependencies for exim? This is just an example. >Just tell dselect to uninstall E and F. Where is the problem? Manual intervention is necessary here. Most people will see this as a bad bug in the E and F packages. >You will only have to do this once and dselect will remember that you >don't want E and F installed (unless they are required later by another >package). Everybody using B will have to do this once. >The dependency rule is still useful for those who trust Debian having >good defaults and want to forget about extra packages. Why would anybody want to forget about extra packages? >The deborphan package provides a much better way of getting rid of >unwanted packages which are installed only because of dependencies, >have not you tried it? I am locally using debfoster. But not all people do that. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Should we allow packages to depend on packages with lower priority values?
On Tue, 9 Dec 2003 12:56:07 +0100 (CET), Santiago Vila <[EMAIL PROTECTED]> wrote: >Because the fact that there should not be conflicts among optional or >higher packages often forces Debian to choose which one, among a set >of packages which conflict at each other, should be the optional or >the standard one and put all the others in extra. I see your point. >By choosing only among optional or higher packages (i.e. forgetting >about extra), a novice user which want to avoid problems will: > >a) find at least some "recommended" package for every task for which >there are several incompatible packages. > >b) not need to bother about resolving conflicts at all. > >This is not about CD creation at all. So this should be supported by a package selecting utility that could be configured to not display any low priority packages, but to pull in packages if they are depended on. I see, if an extra package is depended on that conflicts with a standard package, we are in for a problem. How about relaxing the priority depends rule to: "Packages of priority required, important, standard and optional must not depend on packages with priority extra". In my example, E and F could be Priority optional then, which is the appropriate value. >> >Just tell dselect to uninstall E and F. Where is the problem? >> >> Manual intervention is necessary here. Most people will see this as a >> bad bug in the E and F packages. > >Most people would see that as a bug if dselect didn't honor your >request of uninstalling E and F, but dselect does honor such requests. So people are required to manually undo mindless automatic installations because of a broken priority setting? >> >You will only have to do this once and dselect will remember that you >> >don't want E and F installed (unless they are required later by another >> >package). >> >> Everybody using B will have to do this once. > >They don't really *have* to do it. Packages E and F will typically be >libraries, which do nothing if no package uses them. Having them >installed is completely harmless. If you think asking a bunch of debconf questions that will never be actually used and taking up hard disk space and inodes is harmless, yes. >They can remove E and F if they don't want to have them installed, but >this has only to be made *once*. Once per installation which can be a major nuisance. >I don't understand why you make such a big problem from uninstalling a >package which you don't want. Why don't you just propose to downgrade >all important and standard packages to optional, then, since >uninstalling those which you don't want is such a big problem? The major problem for me is that this installation happens on already installed systems. For new installations, pulling in the packages is fine - when I do a new installation, I expect to uninstall a bunch of unwanted packages. During an upgrade, I expect that only these new packages are installed that are really needed. Usually, this is what Debian does. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Should we allow packages to depend on packages with lower priority values?
On Thu, 11 Dec 2003 17:25:07 -0700, Paul E Condon <[EMAIL PROTECTED]> wrote: >My understanding of the issue in the original post of this thread is >that situations can arrise where Debian policy forbids including some >package on a CD in a way that the poster thinks it should be >included. I suppose he is an advocate of some package and wants it to >have a better position on the supermarket shelf. The answer I'm >getting to my questions seems to support the position that priorities >is a somewhat arbitrary system for including some packages and >excluding others. No. The original problem is that currently policy requires helper packages that are needed by an important package to be important as well. This causes these helper packages to be installed by dselect even if they're not needed. In fact, I am an advocate and a co-maintainer of a package that already has a very prominent place on the supermarket shelf, and I would like to be allowed to place some helpers on a less prominent place so that they're not accidentally bought by somebody who does not want the main product. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Should we allow packages to depend on packages with lower priority values?
On Sat, 20 Dec 2003 06:01:17 -0700, Paul E Condon <[EMAIL PROTECTED]> wrote: >From my experience as a user, package categories complicate user >understanding without any apparent benefit. When I first read about >them I was puzzled as to why they exist. My current thinking is that >they somehow simplify the process of placing packages on CDs in the >official release. It is good to have things arranged in such a way >that a new user can get started with just one CD, and it is good >to have some heuristics for finding such an arrangement. But I >wonder; should these heuristics be part of a grand policy? They should. The current priority system contains the selection about which package gets installed by default if there are multiple packages doing the same thing. And it allows vendors who decide to pre-install Debian on new systems to blindly install everything down to optional without conflicts. That might be a stupid decision, but they can shit a conflict free complete system then. All these things could be solved by allowing dependencies to be in lower priorities and resolving dependencies when building a "standard only" or "everything non-extra" system. >Again, I'm sorry for having misrepresented your position. >Please, excuse me. No problem. I am not a native speaker and have most probably worded an unclear proposal. Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Bug#333862: debian-policy: Policy forbids account creation
Package: debian-policy Version: 3.6.2.1 Severity: normal Policy 9.2.1 says: Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow. This makes, for example, the passwd package RC buggy since useradd modifies /etc/passwd. Also exim4 is RC buggy since its maintainer scripts modify /etc/passwd by calling adduser which in turn calls useradd which in turn modifies /etc/passwd while not belonging to base-passwd. The section in the policy should say Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow directly from their maintainer scripts. Greetings Marc -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-zgsrv Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: deluser on purge (was: Piuparts testing status update)
On Tue, Nov 14, 2006 at 06:12:24PM -0800, Russ Allbery wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > In the case of adduser, there is a strong case for not doing deluser at > > *all* on purge, because it's impossible to ensure that there are no > > off-line or remote resources referencing the uid/gid. > > This is something that I'd really like to see us sort out in policy, since > I think we should be able to describe consistent behavior with regard to > system users and package purging to our users. http://wiki.debian.org/AccountHandlingInMaintainerScripts Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: deluser on purge (was: Piuparts testing status update)
On Tue, Nov 14, 2006 at 10:01:16PM -0800, Don Armstrong wrote: > On Tue, 14 Nov 2006, Russ Allbery wrote: > > This is something that I'd really like to see us sort out in policy, > > since I think we should be able to describe consistent behavior with > > regard to system users and package purging to our users. > > What makes the most sense to me is to not delete the user, and warn > that this has not been done. (I'm really not sure how best to do the > warning besides outputing to STDERR.) There could be a cron job sending a weekly mail listing all users that are orphans from purged packages. That cron job should honor a white list of local orphan accounts that should not be listed. And there should be a tool to remove (one/all) orphan user(s). > This avoids the obvious problems with deleting a user who may still > own files on the system, and then recreating a different username for > a different program with the same uid which shouldn't have access to > those files The issue are files on offline media or on NFS shared that were not mounted at package purge. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should executables be permitted to update themselves?
On Sun, Jan 14, 2007 at 12:26:15AM -0500, Michael Gilbert wrote: > is there a policy on whether an executable is permitted to update itself? i > personally believe that in order to maintain the security of the system, apt > and apt alone should be used to install software updates. recently i > submitted a bug on azureus about how it should not urge users to install > updates outside of apt (http://bugs.debian.org/405997), which was quickly > closed by the maintainer. jftr, the bug was not closed, but tagged wontfix. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/mailname clarfication
On Tue, Jun 21, 2005 at 10:24:41AM -0500, John Goerzen wrote: > I believe that /etc/mailname should be the host part of the e-mail > address. Postfix, sendmail, reportbug, and most other programs I've > used treat it that way. As mentioned in http://wiki.debian.net/?EtcMailName, exim4 does handle /etc/mailname in the same way. exim4 uses /etc/mailname to qualify recipients. > The Exim4 maintainer believes that /etc/mailname should instead be the > hostname as visible in Received lines. No, I do not believe that. In fact, I have not been able to verify the claims John makes on my test system. I have tried reproducing his setup in my lab, and the Received headers come out just fine. See my messages to bug #315128. John, can you please try to find out what happens on your system? I suspect that your /etc/hosts resolves your local IP address as "complete.org", while that one should definetely resolve to the actual host name. > In my case, I want fritz.complete.org to be in Received, and > complete.org in From lines. Exim4 expects fritz.complete.org to be in > /etc/mailname, and thus messes up all sorts of other programs. I do not think that Exim4 expects fritz.complete.org to be in /etc/mailname. > The Exim4 maintainer would like clarficiation in policy about this > issue. Not only about this issue, but about the issues raised in http://wiki.debian.net/?EtcMailName as well. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#1006912: is it time to have account deletion in policy?
On Wed, Mar 09, 2022 at 09:46:13PM +0100, Marc Haber wrote: > Adduser development has regaind momentum, so I see it possible that we > get the necessary adduser changes in Debian before bookworm so that we > can, as a second step, amend policy and debhelper. That obviously didn't happen for bookworm, and neither for trixie, but we're working on it. The policy patch still looks good and valid, so we're still waiting for adduser to come up with the changes. Thanks for your patience and for not holding your breath. Greetings Marc
