Re: Best practices for development workstations

2011-01-17 Thread Yaroslav Halchenko
Hi Manoj, Could you please briefly outline (or may be you have it described somewhere already) the setup of your SELinux-fortified building environment? I am still boiling the idea of securing/monitoring build environment, issue I have raised in securing/monitoring Debian devel environment

Re: Best practices for development workstations

2010-04-05 Thread Carsten Hey
* John Goerzen jgoer...@complete.org [2010-03-29 19:03 -0500]: Suggestions? Sounds like you should consider trying vserver or similar. It consumes less resources than real virtualisation but provides better networking isolation than simple chroots. You would need a kernel with vserver support

Re: Best practices for development workstations

2010-04-05 Thread Mikhail Gusarov
Twas brillig at 19:03:00 29.03.2010 UTC-05 when jgoer...@complete.org did gyre and gimble: JG Suggestions? LXC -- http://fossarchy.blogspot.com/ pgpcng6MxJDnP.pgp Description: PGP signature

Re: Best practices for development workstations

2010-04-04 Thread Petter Reinholdtsen
[Robert Collins] Wearing my squid upstream hat: please file bugs if squid is misbehaving. Squid is used in many high volume high load web sites, so if there are reliability bugs we really really want to know about them. If you really plan to fix apt and squid related problems, it would be

Re: Best practices for development workstations

2010-04-04 Thread Robert Collins
On Sun, 2010-04-04 at 12:27 +0200, Petter Reinholdtsen wrote: [Robert Collins] Wearing my squid upstream hat: please file bugs if squid is misbehaving. Squid is used in many high volume high load web sites, so if there are reliability bugs we really really want to know about them. If

Re: Best practices for development workstations

2010-04-03 Thread Toni Mueller
Hi, On Wed, 31.03.2010 at 08:46:01 +0100, Holger Levsen hol...@layer-acht.org wrote: On Dienstag, 30. März 2010, Marco Túlio Gontijo e Silva wrote: squid! (Or any other normal http proxy. I don't recommend any apt-proxy solution...) Can you explain why? apt-proxy had issues when

Re: Best practices for development workstations

2010-04-03 Thread Jonathan Niehof
On Sat, Apr 3, 2010 at 11:48 AM, Toni Mueller t...@debian.org wrote: I'm currently test-driving apt-cacher-ng, which has it's own bag of problems so far, but seems to be lighter and so far more reliable than apt-proxy. I've been using it pretty happily to keep several machines updated. The

Re: Best practices for development workstations

2010-04-03 Thread Robert Collins
On Sat, 2010-04-03 at 17:48 +0200, Toni Mueller wrote: Actually, squid has its own slew of problems. Eg. I've yet to see a machine where Squid runs reliably under anything resembling a reasonable load, instead of falling over frequently, and it can be difficult to have the features work

Re: Best practices for development workstations

2010-04-02 Thread Marc Haber
On Tue, 30 Mar 2010 11:14:20 +0200, Wouter Verhelst wou...@debian.org wrote: I've been in this situation ever since I upgraded from potato to woody back in late 2000, right before I became a Debian Developer. I've continued this practice on my work laptops that I often have to take to customers

Re: Best practices for development workstations

2010-03-31 Thread Paul Wise
On Tue, Mar 30, 2010 at 11:24 PM, John Goerzen jgoer...@complete.org wrote: On Tue, Mar 30, 2010 at 09:02:59AM +0800, Paul Wise wrote: On Tue, Mar 30, 2010 at 8:03 AM, John Goerzen jgoer...@complete.org wrote: 1. workstation running sid I used that until DebConf9 when I reinstalled and

Re: Best practices for development workstations

2010-03-31 Thread Holger Levsen
Hi, On Dienstag, 30. März 2010, Marco Túlio Gontijo e Silva wrote: squid! (Or any other normal http proxy. I don't recommend any apt-proxy solution...) Can you explain why? apt-proxy had issues when I tried (as well as others, which I cannot rememeber now), approx iirc requires to

Re: Best practices for development workstations

2010-03-31 Thread Jean-Christophe Dubacq
On Wed, Mar 31, 2010 at 02:44:48PM +0800, Paul Wise wrote: I'm having a bit of trouble visualizing how that works; can you spell out your apt settings? Something like this (not my exact settings): Package: * Pin: release a=stable Pin-Priority: 700 Package: * Pin: release a=testing

Re: Best practices for development workstations

2010-03-31 Thread Filippo Giunchedi
Hi, On Mon, Mar 29, 2010 at 07:03:00PM -0500, John Goerzen wrote: 2a. pbuilder pbuilder, or some other chroot such as schroot, can help. In theory, it is a good plan. I don't have to dedicate a lot of RAM to it. The problem is that a chroot doesn't establish terribly strict separation

Re: Best practices for development workstations

2010-03-31 Thread Peter Samuelson
[Filippo Giunchedi] pbuilder sets up /usr/sbin/policy-rc.d to exit 101 so if a daemon starts out of your control (e.g. with /etc/init.d/daemon start) you have found a bug somewhere in a package, no? I've not seen daemons randomly starting lately. Well, one point of a non-sid system with a

Re: Best practices for development workstations

2010-03-31 Thread Simon Paillard
On Wed, Mar 31, 2010 at 08:46:01AM +0100, Holger Levsen wrote: On Dienstag, 30. März 2010, Marco Túlio Gontijo e Silva wrote: squid! (Or any other normal http proxy. I don't recommend any apt-proxy solution...) Can you explain why? apt-proxy had issues when I tried (as well as

Re: Best practices for development workstations

2010-03-30 Thread Wouter Verhelst
On Mon, Mar 29, 2010 at 07:03:00PM -0500, John Goerzen wrote: Hi folks, I'm trying to solicit comments on what people are using for development environments and how well it's working. Here are some situations I imagine are common: 1. workstation running sid I've followed this model

Re: Best practices for development workstations

2010-03-30 Thread Holger Levsen
Hi John, On Dienstag, 30. März 2010, John Goerzen wrote: The ability to easily rebuild a chroot is appealing. However, I do not have a fast mirror at home; my broadband connection is just barely broadband. pbuilder highly recommends a local or a fast mirror. So I am concerned about this

Re: Best practices for development workstations

2010-03-30 Thread Marco Túlio Gontijo e Silva
Hi Holger. Excerpts from Holger Levsen's message of Ter Mar 30 09:56:34 -0300 2010: (...) On Dienstag, 30. März 2010, John Goerzen wrote: The ability to easily rebuild a chroot is appealing. However, I do not have a fast mirror at home; my broadband connection is just barely broadband.

Re: Best practices for development workstations

2010-03-30 Thread John Goerzen
Paul Wise wrote: So I am concerned about this approach for security reasons as well. Could you detail your concerns here? That was a braino. I meant to say *performance* reasons. -- John -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe.

Re: Best practices for development workstations

2010-03-30 Thread John Goerzen
On Mon, Mar 29, 2010 at 05:43:06PM -0700, Russ Allbery wrote: John Goerzen jgoer...@complete.org writes: I use a combination of the two of these except with testing on my primary workstation (the one that I can't afford to have go down), but list and deprioritize sid in sources.list on the

Re: Best practices for development workstations

2010-03-30 Thread John Goerzen
On Tue, Mar 30, 2010 at 09:02:59AM +0800, Paul Wise wrote: On Tue, Mar 30, 2010 at 8:03 AM, John Goerzen jgoer...@complete.org wrote: 1. workstation running sid I used that until DebConf9 when I reinstalled and switched from i386 to amd64. 2. workstation running squeeze or lenny At

Re: Best practices for development workstations

2010-03-30 Thread Russ Allbery
John Goerzen jgoer...@complete.org writes: One other potential problem with having my build environment be the same as my workstation: I sometimes have non-Debian packages installed (MythTV, nvidia drivers, other stuff I'm working on, etc.) that I occasionally worry could cause dependency

Best practices for development workstations

2010-03-29 Thread John Goerzen
Hi folks, I'm trying to solicit comments on what people are using for development environments and how well it's working. Here are some situations I imagine are common: 1. workstation running sid I've followed this model for over a decade. It works well, in general, and I keep up with

Re: Best practices for development workstations

2010-03-29 Thread Russ Allbery
John Goerzen jgoer...@complete.org writes: 1. workstation running sid I've followed this model for over a decade. It works well, in general, and I keep up with development well enough that I can fix problems when they arise. However, it tends to lead to a certain amount of cruft over the

Re: Best practices for development workstations

2010-03-29 Thread Paul Wise
On Tue, Mar 30, 2010 at 8:03 AM, John Goerzen jgoer...@complete.org wrote: 1. workstation running sid I used that until DebConf9 when I reinstalled and switched from i386 to amd64. 2. workstation running squeeze or lenny At the moment I have only one workstation (a laptop). I use testing,

Re: Best practices for development workstations

2010-03-29 Thread Manoj Srivastava
On Mon, Mar 29 2010, John Goerzen wrote: Hi folks, I'm trying to solicit comments on what people are using for development environments and how well it's working. Here are some situations I imagine are common: 1. workstation running sid 2b. Xen, KVM, qemu, or VirtualBox I have