On Sun, May 13, 2012 at 09:56:17AM -0700, Russ Allbery wrote:
> packaging and security issues and is because we need N independent
> installations per server for different groups that can vary separately and

That's one reason why packaged versions of web apps are quite often
useless at my workplace, too.

> We're finding it very hard to use the packaged versions of large web
> application frameworks for a variety of reasons. One of the big ones is
> that web developers seem to expect a very fast upgrade cycle that's hard

The requirement for fast upgrade cycles partly stems from the huge
attack surface that Internet-facing web apps have. It also stems from
the generally short turnaround times for new releases of software and
applications built on top of said web apps, as users keep demanding more
and newer features.

> to support in Debian; another is that it is really helpful for web
> applications to be able to give an entirely independent installation to
> each major site rather than trying to share the same code. For another

Ack. That's also one factor driving the demand for virtual servers (xen,
kvm, you-name-it).


Just my 0.02 cents...


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: 20120514130420.GA8341@spruce.wiehl.oeko.net">http://lists.debian.org/20120514130420.GA8341@spruce.wiehl.oeko.net

On Mon, May 14, 2012 at 03:04:20PM +0200, Toni Mueller wrote:
> > to support in Debian; another is that it is really helpful for web
> > applications to be able to give an entirely independent installation to
> > each major site rather than trying to share the same code. For another
>
> Ack. That's also one factor driving the demand for virtual servers (xen,
> kvm, you-name-it).

This reminds me: is anyone going to bring back vserver or openvz in some
form? Otherwise, wheezy would end up with no containers. Xen does kernel
virtualization and thus takes an order of magnitude more memory, lxc is not
supposed to be secure (it provides a chroot with usage limits, but no
isolation).

I for one wouldn't be too comfortable handling a major security feature
myself, but then, a single ill-prepared person applying such a patch is
better than hundreds or thousands of admins doing that themselves.

Vserver's upstream has been in maintenance mode[1] for quite some time, but
they fix bugs and port to new kernel versions nearly immediately.


[1]. Because "lxc will be ready 'soon'".
--
“This is gonna be as easy as cheating on an ethics exam!�
-Cerise Brightmoon

On Mon, May 14, 2012 at 04:23:27PM +0200, Adam Borowski wrote:
> On Mon, May 14, 2012 at 03:04:20PM +0200, Toni Mueller wrote:
> > > to support in Debian; another is that it is really helpful for web
> > > applications to be able to give an entirely independent installation to
> > > each major site rather than trying to share the same code. For another
> >
> > Ack. That's also one factor driving the demand for virtual servers (xen,
> > kvm, you-name-it).
>
> This reminds me: is anyone going to bring back vserver or openvz in some
> form?

Ola Lundqvist <ola@inguza.com> had plans to do this in an
OpenVZ-hosted repository.

> Otherwise, wheezy would end up with no containers. Xen does kernel
> virtualization and thus takes an order of magnitude more memory, lxc is not
> supposed to be secure (it provides a chroot with usage limits, but no
> isolation).
[...]

User IDs and capabilities aren't yet properly namespaced. So you
can't create a container-root user to manage the container from the
inside, and you can't rent out a container as a VPS.

That doesn't mean we have 'no containers'.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120514145325.GK4038@decadent.org.uk">http://lists.debian.org/20120514145325.GK4038@decadent.org.uk

On Mon, May 14, 2012 at 03:53:25PM +0100, Ben Hutchings wrote:
> On Mon, May 14, 2012 at 04:23:27PM +0200, Adam Borowski wrote:
> > This reminds me: is anyone going to bring back vserver or openvz in some
> > form?
> Ola Lundqvist <ola@inguza.com> had plans to do this in an
> OpenVZ-hosted repository.

Sounds good...

> > Otherwise, wheezy would end up with no containers. Xen does kernel
> > virtualization and thus takes an order of magnitude more memory, lxc is not
> > supposed to be secure (it provides a chroot with usage limits, but no
> > isolation).
> User IDs and capabilities aren't yet properly namespaced. So you
> can't create a container-root user to manage the container from the
> inside, and you can't rent out a container as a VPS.

But that's a major application of this technology.

> That doesn't mean we have 'no containers'.

But in practice, it means that many users have to migrate, or abstain
from upgrading. Or will lxc be completely ready for Wheezy?


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: 20120514145840.GC8341@spruce.wiehl.oeko.net">http://lists.debian.org/20120514145840.GC8341@spruce.wiehl.oeko.net

On May 14, Toni Mueller <toni@debian.org> wrote:

> But in practice, it means that many users have to migrate, or abstain
> from upgrading. Or will lxc be completely ready for Wheezy?
No way, what is missing is important kernel features.
The only hope is that somebody will maintain a decent .deb repackaging
of the openvz Red Hat kernel.
I am interested (and I am generally interested in using Red Hat kernels
on Debian systems), but I cannot offer resources to maintain such a
package right now.

--
ciao,
Marco

El 14/05/12 12:03, Martin Bagge / brother escribió:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2012-05-13 14:54, Yves-Alexis Perez wrote:

Wordpress upstream doesn't seem to be able to support a stable branch
long enough for us (and I don't blame them for that, we do know how
painful it is).

This pretty much sounds like the web browser situation where we don't
support the current version for the entire life cycle of the stable release.
Document and be done with it.
http://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#browser-security
IMHO: while it is true that WordPress can't be properly supported during
all of a stable release's lifetime as it is (the volatile /
squeeze-updates sounds like a very good solution to me), there exist two
different scenarios AFAICS:


* Single-user WordPress, a.k.a "apt-get install lamp-server wordpress"
(assuming the lamp-server meta-package were available in Debian stable)
IMO, It is much better to just tell the user to COPY the codebase
to /{srv,var}/www or the like (or maybe even do it from postinst after
asking) and let WordPress update itself --- no burden for the security
team this way


- or -

* Multi-user WordPress, where the admin uses a single codebase from the
package for all the different installs ( by telling Apache to use
/usr/share/wordpress as its docroot + the wonderful
/etc/wordpress/config-<siteurl>.php magic -- this is what we do here )
This requires some competence on the part of the admin anyway, so
*at worst* updating via wget wordpress-latest.tar.gz + tar xvfz + rsync
is a possibility.


For this case, a wordpress package from "updates" would be best.
Since upstream does not support a version long enough anyway, this would
provide all the benefits from a packaged WP, plus timely enough updates.



I don't know whether there is any other option which complies with
Debian's current security policies (that is, backport security fixes to
the stable branch/no version upgrades) and which allows us to keep the
install reasonably secure. The second one looks feasible to me.


My .02€

Giuseppe and Raphaël (WP maintainers): my most sincere appreciation for
your work. The wp-config.php patches are truly a godsend for
multi-instance installs.



Regards,

J.L.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FB1A520.70905@adv-solutions.net">http://lists.debian.org/4FB1A520.70905@adv-solutions.net