Re: [Letsencrypt-devel] Certbot in Debian Stretch
On Wed, Nov 30, 2016 at 10:34:11PM +0100, Christian Seiler wrote: > Ah, and I ran my strace earlier with -e open,access, but after > rechecking it, it does in fact check for the file's existence > via stat(). I should remember to use -e open,access,stat when > checking for file access with strace. [1] > > And I just checked, putting post-hook = ... in there actually > seems to work (renew -vvv says it won't run the post hook > because nothing is to be renewed, but it won't print that > message if I comment the line out). I do think you could also > improve the documentation for the 'renew' command to mention > that these hooks can be put in the central configuration file, > and to recommend to people to do that instead of supplying > them on the command line - that way people won't have the idea > of modifying the cron job / systemd service for this kind of > thing. Defining hooks in cli.ini doesn't actually work in 0.9.3, but it sort of works in git master, and will be properly solved for 0.10.0: https://github.com/certbot/certbot/issues/3394 https://github.com/certbot/certbot/issues/3394#issuecomment-258579483 > > I've now created /etc/letsencrypt/cli.ini and removed my > drop-in that modifies the systemd service. Thanks, this thread > has already helped me make my setup saner. :) > > Regards, > Christian > > [1] Probably should add openat,fstatat,faccessat to the list > as well. > > -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993
Re: [Letsencrypt-devel] Certbot in Debian Stretch
On Wed, Nov 30, 2016 at 04:19:40PM +0100, Christian Seiler wrote: > On 11/30/2016 02:33 PM, Virgo Pärna wrote: > > On Fri, 25 Nov 2016 15:41:45 +0100, Christian Seiler <christ...@iwakd.de> > > wrote: > >> > >> is not an issue (it works fine), but I had modified the cron job to > >> pass --renew-hook and --post-hook to certbot. (As far as I can tell, > >> there's no way of setting these in a configuration file.) The only > > > > I think that /etc/letsencrypt/cli.ini is supposed to work for it. > > As far as I am aware this is non-standard, and all examples with > that file name I could find would do > > certbot --config /etc/letsencrypt/cli.ini > > However, certbot --help paths clearly states that --config has no > default value, so by default certbot does not read that file, and > strace confirms it. Actually, the only files read in by certbot > in /etc/letsencrypt are /etc/letsencrypt/renewal/$certname.conf > and /etc/letsencrypt/archive/$certname/cert$N.pem. The help is wrong there; that's an instance of this bug: https://github.com/certbot/certbot/issues/3734 https://bugs.python.org/issue28742 I'm adding the --config flag you noticed as another case of that bug. We'll try to get a fix for that (which will probably require vendorng the argparse library) included in upstream Certbot before Stretch freezes ;) -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993
Re: [Letsencrypt-devel] Certbot in Debian Stretch
On Tue, Nov 29, 2016 at 09:59:06AM +0100, Daniel Pocock wrote: > This would probably mean making sure the client is checking the network > API version and giving the user helpful, distro-specific instructions if > there is a mismatch, e.g. a Debian user would see a message "The Let's > Encrypt API no longer supports your client version, it is now essential > for you to install certbot by (running apt-get upgrade | using > $RELEASE_N-backports)" > > To get the message exactly right, it would be useful if the certbot > utility would actually check the apt catalog for both an SRU and > backport and tell the user exactly which one is sufficient to get them > going again. We actually have some code that generates specific instructions of that exact sort; it powers the Web application at https://certbot.eff.org/ ; the source code is here: https://github.com/certbot/website/tree/master/_scripts/instruction-widget Unfortunately, it's written in the wrong language (JavaScript rather than Go) for us to be able to easily have the boulder server return errors that send these instructions to old copies of Certbot. So what we'd probably do is tell people, "please install a copy of Cerbot greater than X; you can go to https://certbot.eff.org/ if you need advice on how to do that on your OS" -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993
Re: [Letsencrypt-devel] Certbot in Debian Stretch
On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote: > Peter, there's one more question embedded within what you have already > asked: > > - would new versions of python-certbot and python-acme require new python > libraries? If yes (or maybe), then the answer would be: go with > stretch-backports. But if you can use whatever will be in next Debian > stable, it might be feasible to negotiate with Debian release team to push > the new upstream releases via s-p-u. (However I am not speaking for or on > behalf of the release team.) We believe that we can avoid having new versions of python-certbot and python-acme depend on new version of Python libraries. In general, we've been trying to relax our dependencies upstream, rather than adding new ones. Over the course of five years it's possible that we'll add new features that do use new libraries or versions of libraries, but I think we can ensure that the features are optional and the depenencies are not strict (ie, they're only Recommends: or Suggests: in Debian packaging terms) -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993
Re: [Letsencrypt-devel] Certbot in Debian Stretch
On Thu, Nov 24, 2016 at 05:37:05PM +0200, Adrian Bunk wrote: > On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote: > > On Thu, Nov 24, 2016, at 13:39, Philipp Kern wrote: > > > So if you, as an upstream maintainer, have a change that is needed for > > > compatibility with changes in network APIs and the change is reviewable > > > by humans, a stable update could be possible. It's still on a > > > case-by-case basis, so you would need to ask and the Release Team cannot > > > approve what they do not know about. > > > > There are more cases where Debian stable is getting new upstream > > releases. > > It's mostly to keep up with the security (MySQL, PHP), > >... > > These are long-term supported upstream stable branches. > > Debian cannot just sacrifice stability by throwing the latest upstream > release of some random packages into stable. That's not what we asked for; we're only interested in having a subset of our upstream releases taken into Debian stable, and only after we know from extensive field testing that they're not breaking anything. We'd be willing to consider defining an upstream stable release series to formalize this, if the Debian community views that as especially important. -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993
Re: [Letsencrypt-devel] Certbot in Debian Stretch
On Fri, Nov 25, 2016 at 12:48:35PM +0100, Christian Seiler wrote: > Note that per backports rules, $RELEASE_N-backports must track > $RELEASE_N_PLUS_1, so if you remove certbot from Stretch, you'll > also have to remove it from jessie-backports. Thank you for pointing this out Christian. This policy removes what might have been the simplest option, and seems to mean that we'll want to work hard on a plan where Certbot is in Stretch in a way that works both for us upstream and for the Debian release team. -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993
Re: [Letsencrypt-devel] Certbot in Debian Stretch
On Sat, Nov 26, 2016 at 09:35:46AM +0800, Paul Wise wrote: > On Tue, Nov 22, 2016 at 9:40 AM, Peter Eckersley wrote: > > > currently working with an ACME backwards compatibilty window of 6-12 months, > > but probably not longer than that. > > I note that letsencrypt 0.4.1-1 (before the rename to certbot) is > available in Ubuntu xenial, which is scheduled for 5 years of support, > terminating in 2021. > > https://people.canonical.com/~ubuntu-archive/madison.cgi?package=letsencrypt+certbot > https://wiki.ubuntu.com/Releases Ubuntu developers have told us that they're likely to take a Xenial SRU to Certbot 0.9.3 shortly: https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1640978 -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993
Re: [Letsencrypt-devel] Certbot in Debian Stretch
On Wed, Nov 23, 2016 at 09:57:19AM +0100, Thijs Kinkhorst wrote: > I'm a bit surprised by this policy. To my knowledge, concepts like automation > and "hassle-free" are central to the Let's Encrypt concept. Obviously are > online for more than a year, so installing Let's Encrypt certificates on them > is not quite automated or hassle-free if you need to upgrade certbot several > times during the projected lifetime of the server. > > Is it really necessary to have such, in my opinion, really short API > lifetimes? > Surely you want to extend and develop it, but this can be done while keeping > compatibility with existing clients in the field. I think this is a pretty profound strategic and philosophical question :) What I hear from the boulder development team is that supporting old versions of the protocol on the server side will greatly complicate their work: they'll either have to maintain many more code paths within a given application (to support different call semantics in different versions of the protocol) or support multiple instances of the CA application talking to the same back-end databases. In one case they'd have to stick with an old version of the Go language, because Go 1.7's standard library implemented better CSR checking, which exposed a Certbot CSR formatting bug. The boulder team's philosophy is to deal with these engineering difficulties by being fairly agressive in pushing clients to take regular updates. They're willing to maintain support for prior protocol versions, but only for a limited amount of time. I think that "get everyone to run the latest and most-correct code" approach is a fairly common attitude especially amongst security-focussed projects. But there are of course drawbacks: it makes life harder for projects that (in relative terms) place a higher priority on stability vs security. And that's a legitimate choice for many purposes. So Let's Encrypt definitely wants to get to a place where we have some very stable APIs for other people to code against. We're trying to do that with the Certbot command line itself, working hard to ensure that if people upgrade, it doesn't break scripts they might have written around the client. And in the long run, I suspect ACME will mature and stabilise too. But it's especially tricky to expect long-run-future-compatibility from a service that's only been online for a year. -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993
Re: Certbot, Ring in Debian Stretch
On Tue, Nov 22, 2016 at 08:23:59AM +0100, Daniel Pocock wrote: > > I'd like to suggest an additional point relevant to all of the options: how > well does the certbot client react when it is no longer usable? Does the > protocol include a mechanism to check the version? Does the client give an > explicit error telling the user to update the client and can it be tweaked > so that Debian users are shown a message about getting the latest package > from stable-backports? Or will the user see some random error that doesn't > mention the client version at all? > ACME includes an explicit versioning mechanism for inherently-breaking protocol changes, and also a User Agent string that an be employed for finer-grained conditional responses. To date, we have never incremented the explicit versioning mechanism, but there have been a couple of incompatibilities that could be characterised as Certbot bugs which the Let's Encrypt servers initially tolerated, but eventually stopped tolerating. In this case: https://github.com/certbot/certbot/issues/2528 the server will today send an error message, and buggy clients would print that error instructing the user to upgrade Certbot and/or OpenSSL to fix the problem. Note, however, that if Certbot is running in a renewal cron job, the sys admin might miss that message. In this case: https://github.com/certbot/certbot/issues/2768 the server was able to use the User Agent string to avoid sending incompatible messages to older Certbot versions. For cases in the future where ACME is intentionally being revised in an inherently incompatible way, we would change the protocol's endpoint URI, and begin a 6-12 month compatibility window with the previous version. In all cases we do have the option of sending email to the registered account email addresses associated with older clients that are about to be incompatible, provided that sys admins chose to give us an email address when they created their Let's Encrypt accounts. -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993
Certbot in Debian Stretch
Hi! I'm an upstream developer for Certbot, previously known as the Let's Encrypt client (https://certbot.eff.org). Certbot is a flexible and very popular way to get certificates from Let's Encrypt; it's issued about 300,000 currently active TLS certs to Debian servers (and a lot more to Ubuntu servers). We hope that over time, a lot of server software can be well-integrated with Certbot in order to use authenticated TLS connections by default (see https://certbot.eff.org/docs/using.html#plugins for some of the integration efforts to date). We're writing to figure out a plan for Certbot versioning and updates for Stretch's stable lifetime. Certbot is still a fairly rapidly-improving, not-quite-1.0 piece of software. The ACME protocol that it uses to talk to Let's Encrypt is also rapidly evolving through an IETF working group (https://datatracker.ietf.org/wg/acme/charter/), and the Let's Encrypt server-side codebase (https://github.com/letsencrypt/boulder) is currently working with an ACME backwards compatibilty window of 6-12 months, but probably not longer than that. In order to both ensure that Certbot remains compatible with the deployed Let's Encrypt service, and to ensure that users have as good an experience as possible when they use Certbot, we do not think it would be wise to support a specific version of Certbot from the Stretch freeze early next year through to the EOL of that release. There seem to be a few options available: 1. Leave Certbot out of the Debian Stretch release, and rely on backports as the recommended way to run Certbot on Debian. That's what we currently do with Jessie: https://certbot.eff.org/#debianjessie-apache 2. Periodically declare a released version of Certbot to be well-tested, stable, and free of detectable regressions or breakage of existing workflows, and include it in Stretch's stable-updates repo. We're currently trying the Ubuntu equivalent of this process out with a proposed xenial SRU from letsencrypt 0.4.1 to Certbot 0.9.3: https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1640978 We expect that such updates would occur every ~3-6 months. If the Debian development community agreed to such a plan, we'd feel comfortable working with it. 3. Someone could maintain a fork of a near-future Certbot release for the ~5 year lifecycle of the Stretch Debian release. The upstream team definitely doesn't think this is a good idea, and we don't have the resources to support such an effort. Looking at the three options above, I think we'd default to doing 1, but we would be open to pursuing option 2 if the Debian developer community supports it, and think there could be advantages in terms of allowing other packages to assume that Certbot is installable, or even Depend: on it, for enabling TLS. -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993
Re: User-Agent strings, privacy and Debian browsers
Yes and no. Although IP addresses are a better tracking mechanism than User-Agent strings, each of them makes the other more effective. If you always browse from one IP, and all the other people at that IP use Windows, then this doesn't help you. But maybe you use open wifi networks, and other Debian users also use those networks. Maybe there are other Debian users behind your NAT. Maybe your friends come over sometimes and they also use Debian. In those cases, standardising the User-Agent string increases the size of your anonymity sets for various activities. On Sep 21, Roberto C. Sánchez [EMAIL PROTECTED] wrote: It would be sort of pointless unless we could find a way to all browse from the same IP address. Regards, -Roberto -- Peter Eckersley[EMAIL PROTECTED] Staff TechnologistTel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: User-Agent strings, privacy and Debian browsers
On Sep 22, Marco D'Itri [EMAIL PROTECTED] wrote: On Sep 22, Peter Eckersley [EMAIL PROTECTED] wrote: This means, in practice, that many sites will be able to track Debian users by their User-Agent, even if (say) the user is blocking cookies or limiting them to a single session and is changing IP address regularly. This is highly debateable. There may be tens or thousands of users of the same package visiting a web site. I've seen reports from very large sites indicating that User-Agent strings are almost as useful as cookies for tracking their users. Would there be any serious harm in terms of browser debugging? Are Yes. For no real gain, it would make debugging harder and make statistics much less useful. When do you need statistics about how many Debian users are using which versions of which browser package? As for debugging, I agree that there's an issue here, which is why I asked the question. But some evidence would be useful... does anyone know any browser or site bugs that have been solved because the site operator could see the version of a random visiting Debian browser? -- Peter Eckersley[EMAIL PROTECTED] Staff TechnologistTel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: User-Agent strings, privacy and Debian browsers
On Sat, Sep 22, 2007 at 11:36:41 +0100, Mark Brown wrote: This means, in practice, that many sites will be able to track Debian users by their User-Agent, even if (say) the user is blocking cookies or limiting them to a single session and is changing IP address regularly. I would strongly expect that any user sufficiently concerned about these issues to take active steps like those would be willing to use things like either the user agent configuration availialbe one way or another in most browsers or something like privoxy (possibly in conjunction with tor) which will do the same things and more. I think this misunderstands the problem. Having stronger privacy is like an insurance policy: most of the people who end up having needed it never knew they were going to need it. So they weren't going to have gone out and installed Privoxy (maybe with Tor) /and/ then examined it closely enough to realise that it doesn't alter their User-Agent by default, and configured it to masquerade as Firefox on Windows or something. Which brings us to a separate point: it's no use to have Privoxy configured to block User-Agent strings, since that means you'll be the one person with no User-Agent, which gives you an even smaller anonymity sets than the default debian packages. Yes, smart users will copy Firefox on Windows, which works -- so long as there isn't one little thing about their browser which gives away their platform. Cos then, they can be identified as the one guy running Iceweasel masquerading as Firefox on Windows. Also, plenty of debian users would have It really does help to have larger groups of people whose browsers are behaving the same way by default. In the case of Privoxy, this would mean having all of the default Privoxy distributions (and especially those that are shipped with Tor) use a single User-Agent. We were also planing to send those trivial Privoxy configuration patches, it'd be great if we could get the community to standardise on Mozilla/5.0 (Privoxy) or something. -- Peter Eckersley[EMAIL PROTECTED] Staff TechnologistTel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
User-Agent strings, privacy and Debian browsers
Consider for a moment a typical User-Agent string sent by a Debian web browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 Iceape/1.1.4 (Debian-1.1.4-1) Unfortunately, the fact that this information identifies a specific package and version of that package means that Debian users (already a select group) have their browsing identities further distinguished by their User-Agent strings. This means, in practice, that many sites will be able to track Debian users by their User-Agent, even if (say) the user is blocking cookies or limiting them to a single session and is changing IP address regularly. What do people think of picking a single User-Agent string for all versions of all of Debian's Gecko-based browsers? Would there be any serious harm in terms of browser debugging? Are there many sites which usefully treat different Gecko browsers differently? As a far more hypothetical question, what would people think of picking a single User-Agent for Gecko-based browsers for a larger set of GNU/Linux distributions? Obviously, there is much more politics there, because any distributions that joined would be losing the ability to measure their desktop market share by looking at web statistics. -- Peter Eckersley[EMAIL PROTECTED] Staff TechnologistTel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An idea from a Debian user
On Thu, Mar 17, 2005 at 12:28:55PM +1100, Evan Cox wrote: My idea is to create a frontend program that is similar to the profile 'Midnight Commander' in Konqueror (ie screen splint into 3/4 top and 1/4 CLI) that begins with iconised area relevant to the administration task, and ends with a screen of relevant commands for the appropriate task and when appropriate some GUI features. From my point of view, a program like this would be a fantastic learning assistant in the crossover from point and click to CLI, and add a central administration section to Debian. This sort of thing could be a great teaching tool. It is not so much related to a distribution like debian, but to the *nix command line in general. Command line shells are extremely powerful, but they were never designed in a coherent and though-out fashion, so they're much harder to learn than, for example, an elegant programming language. The problem with your proposal is that it's an extremely large and complicated task if you want to do it properly. It isn't going to happen unless someone (probably not debian) puts extensive effort into it. It might also be easier to implement a new, less crufty, command line shell (and programmatic interface to standard command line tools) from scratch while one was at it. -- Peter Eckersley Department of Computer Science mailto:[EMAIL PROTECTED] IP Research Institute of Australia http://www.cs.mu.oz.au/~pde The University of Melbourne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solving the compression dilema when rsync-ing Debian versions
On Mon, Jan 08, 2001 at 08:27:53AM +1100, Sam Couter wrote: Otto Wyss [EMAIL PROTECTED] wrote: So why not solve the compression problem at the root? Why not try to change the compression in a way so it does produce a compressed result with the same (or similar) difference rate as the source? Are you going to hack at *every* different kind of file format that you might ever want to rsync, to make it rsync friendly? Surely it makes more sense to make rsync able to more efficiently deal with different formats easily. I think you reach the right conclusion, but for the wrong reason. Either you fix rsync for each of n file formats, or you fix n file formats for rsync :) The advantage of doing it in rsync-land is that you can do a better job; you apply the inverse of the compression format at both ends, calculate the differences, and re-apply compression (probably gzip rather than the original algorithm, but it depends) to these. Trying to hack compression algorithms to fit rsync is in general a bad idea. Rusty could probably get away with it for gzip, because it is very simple - decompression of gzip is interpreting codes like repeat the 17 characters you saw 38 characters ago. Other, more sophisticated algorithms, like bzip2 (go and read about the Burrows-Wheeler Transform, it's amazing ;) would be much harder to hack in any reasonable way. -- | |= -+- |= | | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ pgp8KT0vs0T0R.pgp Description: PGP signature
Re: Solving the compression dilema when rsync-ing Debian versions
On Mon, Jan 08, 2001 at 11:58:26PM +1100, Peter Eckersley wrote: On Mon, Jan 08, 2001 at 08:27:53AM +1100, Sam Couter wrote: Otto Wyss [EMAIL PROTECTED] wrote: So why not solve the compression problem at the root? Why not try to change the compression in a way so it does produce a compressed result with the same (or similar) difference rate as the source? Are you going to hack at *every* different kind of file format that you might ever want to rsync, to make it rsync friendly? Surely it makes more sense to make rsync able to more efficiently deal with different formats easily. I think you reach the right conclusion, but for the wrong reason. Either you fix rsync for each of n file formats, or you fix n file formats for rsync :) The advantage of doing it in rsync-land is that you can do a better job; you apply the inverse of the compression format at both ends, calculate the differences, and re-apply compression (probably gzip rather than the original smacks self in head That wasn't very clear of me, was it? Gzip compression is fine for transferring data on the wire. At the other end, you still need to reuse the original algorithm. Re-applying compression is, of course, a potential problem (as someone pointed out in another thread, even gzip is not in general re-applicable). So more correctly, an rsync module is better where it's possible... algorithm, but it depends) to these. Trying to hack compression algorithms to fit rsync is in general a bad idea. Rusty could probably get away with it for gzip, because it is very simple - decompression of gzip is interpreting codes like repeat the 17 characters you saw 38 characters ago. -- Peter Eckersley http://www.cs.mu.oz.au/~pde ([EMAIL PROTECTED]) TLI: http://www.computerbank.org.au ~sig temporarily conservative pending divine intervention~ GPG fingerprint: 30BF 6A78 2013 DCFA 5985 E255 9D31 4A9A 7574 65BC pgp4KnkuuM3vN.pgp Description: PGP signature
Re: Obsolete software in /usr/local
On Sat, Jan 06, 2001 at 08:23:29PM -0400, Ben Armstrong wrote: On Sat, Jan 06, 2001 at 03:49:07PM -0500, Greg Stark wrote: I've been meaning to bring this up for a while: Why on earth was this change ever made? I can't speak for whoever made the change, but I suspect that it is because LD_LIBRARY_PATH can be used to support libraries in /usr/local/lib for programs in /usr/local/bin without messing up anything that ships with Debian. Otherwise, there exists the possibility that the wrong library will be used. This is especially of concern for developers, who may be putting things in /usr/local/bin and /usr/local/lib to test before releasing a package. We would not want their local libraries to be linked in official Debian packages. That doesn't seem like an elegant explanation. Wouldn't it make more sense to have a script to make sure that a Debian package hasn't got links to whacky non-standard libraries? The current behaviour is rather non-intuitive, and, as Greg said, lots of sysadmins will change it (after wasting time trying to find out what's going on). In any event, looking in bugs.debian.org for the old bug that this change closed might give you more info than this rough guess. The bug isn't there anymore. Does anyone remember what it was? -- | |= -+- |= | | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ pgpR54rMNVxQn.pgp Description: PGP signature
Re: lilo.conf
On Sat, Jan 06, 2001 at 04:12:54AM +0100, Mathias Gygax wrote: On Sam, Jan 06, 2001 at 01:52:17 +1100, Russell Coker wrote: I'll try and make the next version do what you require. well it's not necessary, but what about a boot message like: _-_ _-- __ _ ___ ___-- \ \ -__| _) __-/ \ ___-___-- \ o /)\ --___ ---\__/ / -__\ --_ /\ --__--__ \_/ \_/\ | / | | |___| | | ((_(_)| )_) -:-=] Debian GNU/Linux [=-:-| \_((_(_)|/(_) \ ( \_) :*) Argh. This is terrible. There's no /usr/share/ascii-art! What has Debian been doing all these years? I guess we could resort to append=init=/usr/games/fortune ascii-art to salvage some kind of credibility... -- Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/
Re: Bug#80343: general: Lack of policy on which files should be owned by which user
On Tue, Dec 26, 2000 at 12:38:28PM +0200, Eray Ozkural (exa) wrote: Hamish Moffatt wrote: On Tue, Dec 26, 2000 at 04:43:53AM +0200, Eray Ozkural (exa) wrote: I like using groups to give different sets of rights and I'm annoyed by Debian giving every user his own group. Is that reall necessary? No, but it's a good idea. It makes it much easier to work in directories shared with other users (but not all users), because you don't have to keep changing your umask all the time, or even worse, fixing file permissions because you (or somebody else) forgot to change their umask. I always thought it was a paranoid kind of security feature in Debian. I might be wrong of course. How does giving every user his own group makes it easier for him to share files without system administrator's intervention? I couldn't guite get it, sorry I just woke up but I simply don't understand it. A small example? Other people have provided most of the really useful reasons, but another one, which is denies access rather than providing it: If my I want a file to be readable by everybody *except* user fred, I can set permissions: [EMAIL PROTECTED]:~ ls -l plot-against-fred -rwr--1 pde fred 1 Dec 27 17:12 plot-against-fred Of course, I need root access to do it :( -- | |= -+- |= | | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ pgpPI0gcYjqqT.pgp Description: PGP signature
Re: List of packages needing a new maintainer
On Tue, Dec 26, 2000 at 04:50:58PM +0100, Martin Michlmayr wrote: RFA: gdict -- small GTK app to retrieve definitions from MIT's dictionary server Ummm... it *seems* like gdict has been swallowed by gnome-utils. If that weren't the case, I would have volunteered. -- | |= -+- |= | | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ pgpUW4UzSBT45.pgp Description: PGP signature
Re: Need to clone machines efficiently - help?
On Mon, Dec 25, 2000 at 12:15:50AM -0800, Erik Winn wrote: Hi Folks, I have just started working with a group here in Portland that is taking in old machines and recycling them - putting linux on as the OS (of course ;}). See http://www.freegeek.org for more. Its a non-profit all volunteer thing; and actually one of the people has posted to one of these lists before ... but, apparently things kinda (lamely, IMO) drifted toward a mandrake system -- I think I can turn that around with a little help; I am putting in some good time there and I think that when the realities of maintaining and upgrading rpm systems hits they may change their minds. Cool... we've got an established organisation doing this in Australia now: http://www.computerbank.org.au We're using Debian for all of our systems. Here is the first obstacle - not really a big one, but I spent all day digging around and couldn't really find any tools for this one: we want to be able to clone the machines easily over the local net. Mandrake has a tricky boot floppy that asks only for the eth0 config and then runs a bunch of perl to do the rest of the install non-interactively. I haven't started reading the scripts yet (that's plan B), instead I was hoping that someone had come up with something similar for debian. We are looking at hundreds of boxes already and its really just begun. This was extremely difficult for us at first, simply because the hardware we got was so variable that no standard install was really possible. There was one small shipment of machines with identical disks which we cloned using dd :). Things have got much better lately, since we started receiving corporate donations of largeish groups of modern PCs with similar hardware. The way we've ended up doing it is this: * A debian mirror server * Customised task packages So we start a normal debian install, but then pick task-computerbank-whatever and it's done. A custom task package might play really well with an automated installer, if your hardware is sufficiently uniform to support one. This is really not a huge task - it would just make a nice splash over here if we could come up with something ... I would greatly appreciate recieving help/ideas/advice on this - Note however that I am not actually subscribed to the list at present (sorry, just too much at the moment ) so you can reply to me personally if you like. Thanks very much in advance! I hope we can get this to happen. Good luck with your project. Take a look at Computerbank, and if the goals are close enough, perhaps we should start considering international affiliations (Computerbank has several chapters in different cities, and we've found that this has certainly been to our advantage - international links would be even better). -- | |= -+- |= | | |- | |- |\ Peter Eckersley ([EMAIL PROTECTED]) http://www.cs.mu.oz.au/~pde for techno-leftie inspiration, take a look at http://www.computerbank.org.au/ pgp4lKXf5Bgzz.pgp Description: PGP signature
