FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-31-2010, 07:46 AM
Holger Levsen
 
Default Best practices for development workstations

Hi,

On Dienstag, 30. Mrz 2010, Marco Tlio 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 changes /etc/apt/sources list, squid always
worked for me and never had issues, squid is useful for more then just
proxying apt repositories, squid can be set up as a transparent proxy quite
easily, updating a full/partial mirror usually takes more bandwidth then just
using a proxy.


cheers,
Holger
 
Old 03-31-2010, 08:39 AM
Filippo Giunchedi
 
Default Best practices for development workstations

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
> from the main environment. Despite promises to the contrary, I've had
> weird things happen; for instance, an MTA, database server, or some
> other daemon process might try to fire up from within the chroot, which
> can result in highly confusing situations. I am therefore somewhat
> uncomfortable with this prospect.

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.

FWIW I'm using cowbuilder for the most used chroots as others have suggested
and regular tar.gz with pbuilder for the less used chroots.

> 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 approach for security reasons as well.

I'm using apt-cacher-ng for both my laptop (sid) and the chroots I use to
build packages in (lenny, squeeze, sid both x86 and x86-64) which has the nice
side effect of being able to downgrade packages offline (and not keeping
/var/cache/apt/archives/ around).

> 2b. Xen, KVM, qemu, or VirtualBox
>
> The advantage of this approach is that it provides more complete
> isolation from the host workstation. I need not worry about it firing
> up a second copy of cron, for instance. On the other hand, it will have
> less perfect integration with the host environment (though NFS and ssh
> could probably let me write a script like pdebuild). It will also
> consume more resources, and especially more RAM and disk space, neither
> of which can be as easily scaled up and down in this setup.

On the side of isolation without too much overhead you could try also lxc with
a recent kernel, it seems like a viable solution already.

filippo


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100331083920.GM15496@esaurito.net">http://lists.debian.org/20100331083920.GM15496@esaurito.net
 
Old 03-31-2010, 09:00 AM
Jean-Christophe Dubacq
 
Default Best practices for development workstations

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
> Pin-Priority: 650
>
> Package: *
> Pin: release a=unstable
> Pin-Priority: 600
>
> Package: *
> Pin: release a=experimental
> Pin-Priority: 550
>
> The priorities need to be > 500 and < 1000.

==> /etc/apt/preferences.d/experimental <==
Package: *
Pin: release a=experimental
Pin-Priority: 50

==> /etc/apt/preferences.d/testing <==
Package: *
Pin: release a=testing
Pin-Priority: 800

==> /etc/apt/preferences.d/unstable <==
Package: *
Pin: release a=unstable
Pin-Priority: 700

==> /etc/apt/preferences.d/stable <==
Package: *
Pin: release a=stable
Pin-Priority: 500

(actually I do not have the last one: 500 is the value given to
non-specified versions). If you have a default release, it is given
990 without any other intervention.

What you should care for is giving priorities between 101 and 989 to
non-default release. I use a script called apt-origins to check where
my packages come from (for example, I only have unison-2.13.16 and xpdf
installed from stable).

I prefer to always rate stable lower than testing, because a package
that is no more in testing but is in stable is suspicious at best (it
was removed from testing at some point).

And for the rest of the thread, I use pbuilder chroots. Testing of
non-controversial packages goes on either my home box (unstable/testing,
arch=amd64) or my lab box (testing/unstable, arch=amd64 kernel+i386
userland) or my laptop (testing/unstable, arch=i386). The more complicated
things I have a kvm virtual machine for, except for drivers and such.

Sincerly
--
Jean-Christophe Dubacq


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100331090029.GA9202@oberon.tenebreuse.org">http://lists.debian.org/20100331090029.GA9202@oberon.tenebreuse.org
 
Old 03-31-2010, 06:36 PM
Peter Samuelson
 
Default Best practices for development workstations

[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 sid chroot is to shield the
host system from bugs in sid. And John is right that chroots are
imperfect for this, and that the problems are not just theoretical but
have happened many times in practice.

I agree with you, though, that as a heavy user of pbuilder/cowbuilder,
I haven't seen such problems on _my_ systems in a fairly long time.

> > 2b. Xen, KVM, qemu, or VirtualBox
> >
> > The advantage of this approach is that it provides more complete
> > isolation from the host workstation. I need not worry about it
> > firing up a second copy of cron, for instance. On the other hand,
> > it will have less perfect integration with the host environment
> > (though NFS and ssh could probably let me write a script like
> > pdebuild).

These platforms support some form of hostfs, don't they? I thought
they did, anyway.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100331183657.GW18278@p12n.org">http://lists.debian.org/20100331183657.GW18278@p12n.org
 
Old 03-31-2010, 08:47 PM
Simon Paillard
 
Default Best practices for development workstations

On Wed, Mar 31, 2010 at 08:46:01AM +0100, Holger Levsen wrote:
> On Dienstag, 30. Mrz 2010, Marco Tlio 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 changes /etc/apt/sources list, squid always
> worked for me and never had issues, squid is useful for more then just
> proxying apt repositories, squid can be set up as a transparent proxy quite
> easily, updating a full/partial mirror usually takes more bandwidth then just
> using a proxy.

Among specific deb repos proxies, "people" seem to be happy with
apt-cacher-ng (at least on debian-mirrors@ldo), and popcon confirms this
impression (best progression):
http://qa.debian.org/popcon-graph.php?packages=apt-cacher-ng%2Capt-cacher%2Capprox%2Capt-proxy%2Cdebmirror%2Capt-mirror&show_vote=on&want_legend=on&want_ticks=on&b eenhere=1

--
Simon Paillard


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100331204738.GK1959@dedibox.ebzao.info">http://lists.debian.org/20100331204738.GK1959@dedibox.ebzao.info
 
Old 04-02-2010, 08:26 AM
Marc Haber
 
Default Best practices for development workstations

On Tue, 30 Mar 2010 11:14:20 +0200, Wouter Verhelst
<wouter@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 to work -- so they have to work reliably for me.

I started running sid on my personal workstations in 2003, and have
never seen a situation where I wasn't able to work due to a sid
breakage.

I know that I was lucky.

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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: E1NxcCc-0000kB-8R@swivel.zugschlus.de">http://lists.debian.org/E1NxcCc-0000kB-8R@swivel.zugschlus.de
 
Old 04-03-2010, 03:48 PM
Toni Mueller
 
Default Best practices for development workstations

Hi,

On Wed, 31.03.2010 at 08:46:01 +0100, Holger Levsen <holger@layer-acht.org> wrote:
> On Dienstag, 30. Mrz 2010, Marco Tlio 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),

me too. Apt-proxy has a very unpleasant tendency to simply hang every
now and then, and has almost been declared deprecated.

> approx iirc requires to changes /etc/apt/sources list, squid always

Yes. You need to point your sources.list to the apt-proxy instance.

> worked for me and never had issues, squid is useful for more then just
> proxying apt repositories, squid can be set up as a transparent proxy quite
> easily, updating a full/partial mirror usually takes more bandwidth then just
> using a proxy.

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 that you want in such a setting.
Eg. Lenny's version of Squid doesn't work for me on Lenny.

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.


Kind regards,

--Toni++


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100403154808.5655.qmail@oak.oeko.net">http://lists.debian.org/20100403154808.5655.qmail@oak.oeko.net
 
Old 04-03-2010, 05:22 PM
Jonathan Niehof
 
Default Best practices for development workstations

On Sat, Apr 3, 2010 at 11:48 AM, Toni Mueller <toni@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 only real problem I've run into is some sort of interaction bug
with Sun^H^H^H^Oracle's VirtualBox repository, where the lists don't
download properly. Last I checked it had turned into a circle of
pointed fingers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: l2h1d23eef01004031022zc079e5bcmeb88241ca707ced9@ma il.gmail.com">http://lists.debian.org/l2h1d23eef01004031022zc079e5bcmeb88241ca707ced9@ma il.gmail.com
 
Old 04-03-2010, 09:06 PM
Robert Collins
 
Default Best practices for development workstations

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 that you want in such a setting.
> Eg. Lenny's version of Squid doesn't work for me on Lenny.

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.

-Rob
 
Old 04-04-2010, 10:27 AM
Petter Reinholdtsen
 
Default Best practices for development workstations

[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
nice if #565555 was fixed.

Also, the default setup for Squid do not allow it to proxy all
packages in the archive (the maximum_object_size is too small). In
Debian Edu, we increased it from 20480 KB to 153600 KB, to allow the
openartwork and fluid-soundfound packages to be proxied. In Debian
Edu, PXE installation is set up out of the box, and to use it for
several machines it is vital to proxy also the big packages.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2flmxxjy0ka.fsf@login2.uio.no">http://lists.debian.org/2flmxxjy0ka.fsf@login2.uio.no
 

Thread Tools




All times are GMT. The time now is 09:23 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org