On Sat, Jan 28, 2012 at 09:41:37PM +0100, Marco d'Itri wrote:
On Jan 27, Wouter Verhelst wou...@debian.org wrote:
Do I understand you correctly that an empty configuration file in /etc
will override its 'full' equivalent in /usr? I.e., just an empty file
full of comments saying this is
On Jan 27, Wouter Verhelst wou...@debian.org wrote:
Do I understand you correctly that an empty configuration file in /etc
will override its 'full' equivalent in /usr? I.e., just an empty file
full of comments saying this is what you can do with this file will
break some things?
This is
On Sat, 28 Jan 2012 21:41:37 +0100, Marco d'Itri m...@linux.it wrote:
On Jan 27, Wouter Verhelst wou...@debian.org wrote:
Do I understand you correctly that an empty configuration file in /etc
will override its 'full' equivalent in /usr? I.e., just an empty file
full of comments saying
On Jan 28, Philip Hands p...@hands.com wrote:
Marvelous -- I particularly like his Separate /usr has become
increasingly unsupported anyway. which reminds me of the argument for
Software Patents in Europe, which is that the EPO have been issuing
Software Patents in defiance of the law for
Sorry for picking up this old thread, but...
On Mon, Jan 02, 2012 at 01:38:56AM +0100, Marco d'Itri wrote:
On Dec 31, Russ Allbery r...@debian.org wrote:
Note that Steve's point, namely that he (if I'm reading him right) thinks
that the upstream changes are being overstated and that
On Fri, Jan 27, 2012 at 10:46:07AM +0100, Wouter Verhelst wrote:
While I agree that forking upstream is not necessarily the right thing
to do, allow me to ask some things just so I understand things
better...
Do I understand you correctly that an empty configuration file in /etc
will
Thomas Goirand z...@debian.org writes:
On 12/22/2011 07:07 PM, Russell Coker wrote:
It seems to me that wanting to have / outside LVM but /usr inside LVM is a
fairly obscure corner case.
I have about 100 servers setup this way, and my laptops as well. I really
don't see why this would be a
On Fri, Jan 6, 2012 at 4:56 AM, Romain Beauxis wrote:
2012/1/5 Paul Wise p...@debian.org:
In my opinion it is a pretty ugly hack that we should discourage where
possible.
There is a trade-off to consider between patching every single webapp,
having no writable location at all and placing
Hi,
2012/1/5 Paul Wise p...@debian.org:
On Thu, Jan 5, 2012 at 11:32 AM, Romain Beauxis wrote:
I once proposed to push for a general policy regarding this symlink
trick for webapps and even to write a debhelper but it did not seem to
appeal to anyone. I am still convinced, though, that it
Enrico Weigelt, 2012-01-04 02:10+0100:
Well, *I* would be *very* suprised by having packaged files under /var.
So I would have changed the app to (additionally) look for plugins
under /usr (in this case /usr/share/dokuwiki/plugin/)
If you are willing to prepare a patch implementing that, I
On Sun, 01 Jan 2012 at 20:20:42 +, Tanguy Ortolo wrote:
Enrico Weigelt, 2011-12-31 03:55+0100:
IMHO this is completely wrong, those files should be under
/usr/lib/... or maybe even /usr/share/... as they're not
dynamic data.
Well, when people install new plugins or new themes, they
Hi all,
2012/1/4 Simon McVittie s...@debian.org:
On Sun, 01 Jan 2012 at 20:20:42 +, Tanguy Ortolo wrote:
Enrico Weigelt, 2011-12-31 03:55+0100:
IMHO this is completely wrong, those files should be under
/usr/lib/... or maybe even /usr/share/... as they're not
dynamic data.
Well,
On Thu, Jan 5, 2012 at 11:32 AM, Romain Beauxis wrote:
I once proposed to push for a general policy regarding this symlink
trick for webapps and even to write a debhelper but it did not seem to
appeal to anyone. I am still convinced, though, that it should be
standard practice.
In my opinion
On Thu, 5 Jan 2012, Romain Beauxis to...@rastageeks.org wrote:
The same was also done for mediawiki at least when I was maintaining
it. I also wish the wordpress packagers would do the same in order to
be able to install plugins and themes simply.
I don't think it's desirable to have such a
On Jan 03, Russ Allbery r...@debian.org wrote:
Yes. But it needs to actually be a co-maintainer, or it needs to be
someone who's offering to be a new upstream, not someone who is willing to
produce a one-time fix to the problem.
And we are not discussing a missing fix, but radically modifying
* Fernando Lemos fernando...@gmail.com schrieb:
Are you guys applying for maintainership for this huge delta
you want to introduce between upstream and us?
Actually, yes.
cu
--
--
Enrico Weigelt, metux IT service --
* Russ Allbery r...@debian.org schrieb:
That experience aside, we're not talking about patches here, assuming
Marco's description of the situation is correct. We're talking about a
full-blown fork and a need for a new udev upstream.
Maybe a downstream-branch is enough.
cu
--
* Tanguy Ortolo tanguy+deb...@ortolo.eu schrieb:
Enrico Weigelt, 2011-12-31 03:55+0100:
IMHO this is completely wrong, those files should be under
/usr/lib/... or maybe even /usr/share/... as they're not
dynamic data.
Well, when people install new plugins or new themes, they get
* Russ Allbery r...@debian.org [120101 19:12]:
If the maintainer refuses patches and only wants to fix brokeness if
someone does a full blown upstream fork then this is a maintainer issue.
I think this discussion is getting hopelessly muddled by excessive use of
sweeping statements like
Thank you for the list. That does make things clearer.
Bernhard R. Link brl...@debian.org writes:
1) Debian contributors are volunteers, they are not be forced to do some
work.
2) Packages, especially those not avoidable in a Debian installation,
are no personal property.
[...]
6)
On 01/01/2012 03:11 PM, Russ Allbery wrote:
Thomas Goirand tho...@goirand.fr writes:
On 01/01/2012 01:49 AM, brian m. carlson wrote:
So the only sane thing to do is not change the default, ever.
The other sane way is to mark files not in /etc as conffiles. It
* Russ Allbery r...@debian.org [111231 18:41]:
Bernhard R. Link brl...@debian.org writes:
My experience is rather that people usually stick to their core packages
as personal property and won't except patches to make them more well
behaved.
That experience aside, we're not talking about
* Josselin Mouette j...@debian.org [111231 10:54]:
Le samedi 31 décembre 2011 à 10:23 +0100, Bernhard R. Link a écrit :
If people maintain some core piece of software and want to decide what
the package looks like, listen to what other people want.
If you want to use too much work as
On 12/21/2011 11:55 AM, Russell Coker wrote:
Nowadays 100G disks are small by laptop standards and for desktops 1TB is
about the smallest that anyone would buy.
Focussing on the desktop is the core of this - imho - misguided idea.
I'd still like to be able have a small, self-contained, Debian
On Sun, 1 Jan 2012, Toni Mueller t...@debian.org wrote:
On 12/21/2011 11:55 AM, Russell Coker wrote:
Nowadays 100G disks are small by laptop standards and for desktops 1TB is
about the smallest that anyone would buy.
Focussing on the desktop is the core of this - imho - misguided idea.
Le dimanche 01 janvier 2012 à 13:02 +0100, Bernhard R. Link a écrit :
Because it’s well-known that filing RFAs will magically generate
competent maintainers with a lot of time in their hands.
Spare your sarcasm, please.
No. I’m sick of these repeated allusions, really. If you are not
Russell Coker russ...@coker.com.au writes:
Do we have Debian running on phones with a configuration such that the root
filesystem is small but /usr can be bigger?
My openmoko has just
$ df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 3.8G 3.0G 626M 83% /
tmpfs
On Sun, Jan 01, 2012 at 05:14:41PM +0800, Thomas Goirand wrote:
On 01/01/2012 03:11 PM, Russ Allbery wrote:
Thomas Goirand tho...@goirand.fr writes:
The other sane way is to mark files not in /etc as conffiles. It
semantically sux a bit, but if we have no choice because of upstream
On Sun, 2012-01-01 at 14:42, Nick Leverton wrote:
On Sun, Jan 01, 2012 at 05:14:41PM +0800, Thomas Goirand wrote:
On 01/01/2012 03:11 PM, Russ Allbery wrote:
Thomas Goirand tho...@goirand.fr writes:
The other sane way is to mark files not in /etc as conffiles. It
semantically sux a
Bernhard R. Link brl...@debian.org writes:
* Russ Allbery r...@debian.org [111231 18:41]:
This isn't about the package. It's about the *software*, the part that
we generally use from upstream as much as possible because asking
people to be both upstream and the Debian package maintainer is
On Sat, Dec 24, 2011 at 11:48:42AM +, Philip Hands wrote:
That might allow us to come up with solutions that are not just:
Everyone must have initramfs, like it or not.
Would we really need that? If I understand correctly, the / to /usr will
merely mean that
People who want to have
Enrico Weigelt, 2011-12-31 03:55+0100:
IMHO this is completely wrong, those files should be under
/usr/lib/... or maybe even /usr/share/... as they're not
dynamic data.
Well, when people install new plugins or new themes, they get installed
on the same directory, so I decided that it was less
Toni Mueller wrote:
On 12/21/2011 11:55 AM, Russell Coker wrote:
Nowadays 100G disks are small by laptop standards and for desktops 1TB is
about the smallest that anyone would buy.
Focussing on the desktop is the core of this - imho - misguided idea.
I'd still like to be able have a
On Dec 31, Russ Allbery r...@debian.org wrote:
ACK. Sometimes upstreams doing really stange things (maybe because they
dont have any package management in mind), that should be fixed. If
upstream doesnt do those fixes, distros have to catch in.
Sometimes, I think Red Hat makes some of
On Jan 01, Riku Voipio riku.voi...@iki.fi wrote:
Would we really need that? If I understand correctly, the / to /usr will
merely mean that
People who want to have /usr on separate partition will need initramfs.
Correct.
It does not even mean that they would need to use initramfs-tools,
* Fernando Lemos fernando...@gmail.com [111231 04:54]:
Are you guys applying for maintainership for this huge delta you want
to introduce between upstream and us? Are you becoming new, reputable
upstreams for that forked software? If not, please refrain from
telling people what to do.
My
Le samedi 31 décembre 2011 à 10:23 +0100, Bernhard R. Link a écrit :
If people maintain some core piece of software and want to decide what
the package looks like, listen to what other people want.
If you want to use too much work as excuse, then file a RFA.
Because it’s well-known that
Bernhard R. Link brl...@debian.org writes:
My experience is rather that people usually stick to their core packages
as personal property and won't except patches to make them more well
behaved.
That experience aside, we're not talking about patches here, assuming
Marco's description of the
On Fri, Dec 30, 2011 at 07:54:34PM -0800, Josh Triplett wrote:
The numerous upstreams which follow this model introduced it
specifically *because* of distributions and package management, which
they specifically had in mind as a design constraint. The search path
behavior, along with the
On Sat, Dec 31, 2011 at 05:49:12PM +, brian m. carlson wrote:
It also either (a) prevents upstream from ever changing that default or
(b) silently breaks packages for the user. If option foo is set to bar
in the upstream configuration and then upstream changes it to baz, the
package
On Sat, Dec 31, 2011 at 08:19:47PM +, Lars Wirzenius wrote:
If the admin has not changed the config, dpkg and ucf will happily
replace the old config with the new one, no questions asked, even
when the config is in /etc. So no change there.
Right. But if the sysadmin customizes any part
On Sun, Jan 1, 2012 at 8:30 AM, brian m. carlson wrote:
Right. But if the sysadmin customizes any part of that configuration—
even something completely unrelated—which is very likely, then he or she
will be prompted. So if the defaults are fine, then the defaults are
likely to be fine in
On 12/31/2011 11:54 AM, Josh Triplett wrote:
Almost all of those bug reports went away once udev moved
the default location of distro-installed rules to /lib/udev/rules.d
rather than /etc/udev/rules.d.
Do you mean it went away, because in /usr/udev/rules.d it's not in
/etc, which
On 01/01/2012 01:49 AM, brian m. carlson wrote:
So the only sane thing to do is not change
the default, ever.
The other sane way is to mark files not in /etc as conffiles.
It semantically sux a bit, but if we have no choice because
of upstream decisions (which we don't have enough time to
Thomas Goirand tho...@goirand.fr writes:
On 01/01/2012 01:49 AM, brian m. carlson wrote:
So the only sane thing to do is not change the default, ever.
The other sane way is to mark files not in /etc as conffiles. It
semantically sux a bit, but if we have no choice because of upstream
Enrico Weigelt, 2011-12-30 06:21+0100:
Which packages ship files in /var ?
Many install directories there. And one of my packages, dokuwiki, also
installs files under /var/lib/dokuwiki/lib/{plugins,tpl}. These files
define the default set of bundled plugins and templates, and I install
them
On Thu, Dec 29, 2011 at 05:36:40PM -0800, Josh Triplett wrote:
top-level directories would look after a move from / to /usr. Also, the
FHS says nothing about the current approach of overriding files in /usr
with files in /etc, which allows packages to stop shipping configuration
files in /etc
On Dec 30, Stephan Seitz stse+deb...@fsing.rootsland.net wrote:
Every package which will accept a configuration file in /etc should
ship such a file in /etc, even if it contains only comments. In this
This train has already passed and you lost it, sorry.
And where do you want to put the
On 30/12/11 12:48, Marco d'Itri wrote:
On Dec 30, Stephan Seitz stse+deb...@fsing.rootsland.net wrote:
Every package which will accept a configuration file in /etc should
ship such a file in /etc, even if it contains only comments. In this
This train has already passed and you lost it,
On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote:
I think that stephan is right here. Every package using files in /etc
It DOES NOT MATTER who is right, some upstreams have decided otherwise.
At least udev, systemd and next month module-init-tools do override the
configuration
On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote:
On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote:
I think that stephan is right here. Every package using files in /etc
It DOES NOT MATTER who is right, some upstreams have decided otherwise.
At least udev, systemd
Carlos Alberto Lopez Perez, 2011-12-30 14:22+0100:
I think that stephan is right here. Every package using files in /etc
should ship this files in the package in order to let the admin know
what package each file belongs to. Its very ugly to do a dpkg -S
/etc/xxx and get a no path found.
Not
On Fri, Dec 30, 2011 at 02:00:23PM +, Tanguy Ortolo wrote:
I think having the default configuration values written in a default
configuration file under /usr is better than having them harcoded, since
it makes it really easier to determine what these defaults are.
It's problematic if the
Stephan Seitz wrote:
Every package which will accept a configuration file in /etc should ship
such a file in /etc, even if it contains only comments. In this way, you
know the name(s) of the configuration file(s) and the subdirectory in
/etc where they belong.
A de-facto standard has already
Josh Triplett, 2011-12-30 16:09+0100:
A de-facto standard has already emerged for how to ship the standard
configuration in /usr/lib and handle overrides,
I do not think this is a de facto standard at all yet. What pieces of
software use apply it? The length of that list should be compared to
Josh Triplett, 2011-12-30 16:09+0100:
A de-facto standard has already emerged for how to ship the standard
configuration in /usr/lib and handle overrides,
I do not think this is a de facto standard at all yet. What pieces of
software use apply it? The length of that list should be
* Tanguy Ortolo tanguy+deb...@ortolo.eu schrieb:
I think having the default configuration values written in a default
configuration file under /usr is better than having them harcoded, since
it makes it really easier to determine what these defaults are. But not
shipping the user
* Carlos Alberto Lopez Perez clo...@igalia.com schrieb:
I think that stephan is right here. Every package using files in /etc
should ship this files in the package in order to let the admin know
what package each file belongs to. Its very ugly to do a dpkg -S
/etc/xxx and get a no path found.
* Tanguy Ortolo tanguy+deb...@ortolo.eu schrieb:
Enrico Weigelt, 2011-12-30 06:21+0100:
Which packages ship files in /var ?
Many install directories there. And one of my packages, dokuwiki, also
installs files under /var/lib/dokuwiki/lib/{plugins,tpl}. These files
define the default set of
* Adam Borowski kilob...@angband.pl schrieb:
On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote:
On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote:
I think that stephan is right here. Every package using files in /etc
It DOES NOT MATTER who is right, some upstreams
Enrico Weigelt wrote:
* Tanguy Ortolo tanguy+deb...@ortolo.eu schrieb:
I think having the default configuration values written in a default
configuration file under /usr is better than having them harcoded, since
it makes it really easier to determine what these defaults are. But not
On Sat, Dec 31, 2011 at 12:59 AM, Enrico Weigelt weig...@metux.de wrote:
* Adam Borowski kilob...@angband.pl schrieb:
On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote:
On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote:
I think that stephan is right here. Every
Enrico Weigelt wrote:
* Adam Borowski kilob...@angband.pl schrieb:
On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote:
On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote:
I think that stephan is right here. Every package using files in /etc
It DOES NOT MATTER
Fernando Lemos fernando...@gmail.com writes:
Enrico Weigelt weig...@metux.de wrote:
ACK. Sometimes upstreams doing really stange things (maybe because they
dont have any package management in mind), that should be fixed. If
upstream doesnt do those fixes, distros have to catch in.
On Mon, Dec 26, 2011 at 05:23:56PM -0800, Steve Langasek wrote:
On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote:
Not quite. Redhat and others want to make this change (moving binaries
and libraries from / into /usr) not just for ease of maintenance (though
that makes sense
* Josh Triplett j...@joshtriplett.org schrieb:
Well aware of that; just trying to fill in the full picture of how the
top-level directories would look after a move from / to /usr. Also, the
FHS says nothing about the current approach of overriding files in /usr
with files in /etc, which
On Tue, Dec 27, 2011 at 08:54:29AM +0100, Josselin Mouette wrote:
Le mardi 27 décembre 2011 à 08:53 +0100, Josselin Mouette a écrit :
Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit :
If someone would give even *one* example where something legitimately needed
by a udev rule
On Tue, Dec 27, 2011 at 08:35:06AM +0100, Bernhard R. Link wrote:
* Andrey Rahmatullin w...@wrar.name [111227 07:53]:
On Mon, Dec 26, 2011 at 06:59:07PM +0100, Bernhard R. Link wrote:
It is a good thing to run with minimum privs, but compiling a new
kernel to
support this seems to
On Tue, Dec 27, 2011 at 08:53:10AM +0100, Josselin Mouette wrote:
Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit :
If someone would give even *one* example where something legitimately needed
by a udev rule could not be moved from /usr to / without breaking interfaces
or
On Sun, Dec 25, 2011 at 12:08:57PM +, Philipp Kern wrote:
On 2011-12-25, Stephan Seitz stse+deb...@fsing.rootsland.net wrote:
All admins I know have at least some servers with custom kernels (in the
past it was said, to build your firewall/server kernels without module
support, so that
On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote:
All admins I know have at least some servers with custom kernels (in the
past it was said, to build your firewall/server kernels without module
support, so that no rootkit module could be loaded).
No longer needed. See
On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote:
On Sun, Dec 25, 2011 at 12:08:57PM +, Philipp Kern wrote:
On 2011-12-25, Stephan Seitz stse+deb...@fsing.rootsland.net wrote:
All admins I know have at least some servers with custom kernels (in the
past it was said, to build
On Mon, Dec 26, 2011 at 04:42:45PM +0600, Andrey Rahmatullin wrote:
On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote:
All admins I know have at least some servers with custom kernels (in the
past it was said, to build your firewall/server kernels without module
support, so
On Mon, 26 Dec 2011, Iustin Pop ius...@debian.org wrote:
No longer needed. See /proc/sys/kernel/modules_disabled.
That's not equivalent - an attacker that can load modules can also
remove the init script that sets this variable to 1 and reboot the
machine.
For many of the things that can
On Dec 26, Russell Coker russ...@coker.com.au wrote:
For many of the things that can be done by loading a kernel module an
attacker
can achieve similar goals by replacing libc or by using ptrace to install
hostile code in a long-running process that runs as root.
Or load code in the kernel
* Philipp Kern pk...@debian.org [111226 12:02]:
Sorry, but what kind of argumentation is that? If the admin doesn't notice
reboots and/or file tampering, I could just replace the kernel with my
modified
one and reboot. Now of course you could increase your paranoia and boot the
kernel from
* Russell Coker russ...@coker.com.au [111226 14:16]:
For many of the things that can be done by loading a kernel module an attacker
can achieve similar goals by replacing libc or by using ptrace to install
hostile code in a long-running process that runs as root.
Except replacing libc does not
On 12/22/2011 07:19 PM, Philip Hands wrote:
I'm still yet to understand the significant upsides of this proposal
So far, the only upside that has been written here, if I understand
well, is less patches for upstream udev, which is important since we
don't have enough people to work on
On 12/22/2011 05:50 PM, Marco d'Itri wrote:
The main objections so far can be summarized as I like to do thing my
way and changes make me unconfortable.
No, the main objection is:
I have already many systems/servers in production already. Please don't
break them.
I don't mind if using an
On 12/09/2011 03:21 PM, Goswin von Brederlow wrote:
As I mentioned I have a bug open (in the grml bug tracker) about
providing a grml.deb. That would install an image in /boot and add
itself to the bootloader. The small grml image is more like 180MB than
25-50MB but it is a verry good rescue
On Dec 26, Thomas Goirand z...@debian.org wrote:
On 12/22/2011 07:19 PM, Philip Hands wrote:
I'm still yet to understand the significant upsides of this proposal
So far, the only upside that has been written here, if I understand
well, is less patches for upstream udev, which is important
On Mon, 26 Dec 2011 20:25:12 +0100, m...@linux.it (Marco d'Itri) wrote:
On Dec 26, Thomas Goirand z...@debian.org wrote:
On 12/22/2011 07:19 PM, Philip Hands wrote:
I'm still yet to understand the significant upsides of this proposal
So far, the only upside that has been written here, if
On 26/12/11 14:15, Russell Coker wrote:
But it seems to me that a more useful feature would be the ability to create
a
white-list of which modules can be loaded to solve the problem of unwanted
triggers for module loading and the problem of buggy kernel modules being
autoloaded in
On Sat, Dec 24, 2011 at 07:03:10PM +0800, Paul Wise wrote:
I'd still like to know what the compelling reason for the change is
though.
Apparently the reason is simply that our upstreams (who it sounds like
are predominantly driven by Redhat folks) are dropping support for /
and /usr on
On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote:
Not quite. Redhat and others want to make this change (moving binaries
and libraries from / into /usr) not just for ease of maintenance (though
that makes sense too) but for several rather interesting reasons. It
would
On 2011-12-26, Bernhard R. Link brl...@debian.org wrote:
* Philipp Kern pk...@debian.org [111226 12:02]:
Sorry, but what kind of argumentation is that? If the admin doesn't notice
reboots and/or file tampering, I could just replace the kernel with my
modified
one and reboot. Now of course
On Mon, Dec 26, 2011 at 06:59:07PM +0100, Bernhard R. Link wrote:
It is a good thing to run with minimum privs, but compiling a new kernel to
support this seems to be a lot of work for a fairly small benefit.
First of all it is quite a significant benefit. And you get quite some
other
On Mon, 2011-12-26 at 22:17 +, Philip Hands wrote:
On Mon, 26 Dec 2011 20:25:12 +0100, m...@linux.it (Marco d'Itri) wrote:
On Dec 26, Thomas Goirand z...@debian.org wrote:
On 12/22/2011 07:19 PM, Philip Hands wrote:
I'm still yet to understand the significant upsides of this
* Andrey Rahmatullin w...@wrar.name [111227 07:53]:
On Mon, Dec 26, 2011 at 06:59:07PM +0100, Bernhard R. Link wrote:
It is a good thing to run with minimum privs, but compiling a new kernel
to
support this seems to be a lot of work for a fairly small benefit.
First of all it is quite
Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit :
If someone would give even *one* example where something legitimately needed
by a udev rule could not be moved from /usr to / without breaking interfaces
or otherwise complicating matters, then that would be worth discussing.
Le mardi 27 décembre 2011 à 08:53 +0100, Josselin Mouette a écrit :
Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit :
If someone would give even *one* example where something legitimately needed
by a udev rule could not be moved from /usr to / without breaking interfaces
* Philipp Kern tr...@philkern.de [111227 04:04]:
As you pointed out so nicely: modules_disabled is only a replacement if
you have a custom initramfs and do not allow that to be modified
automatically. So from the point of the original discussion,
modules_disabled is no solution.
You just
On 12/22/2011 07:07 PM, Russell Coker wrote:
It seems to me that wanting to have / outside LVM but /usr inside LVM is a
fairly obscure corner case.
I have about 100 servers setup this way, and my laptops as well. I really
don't see why this would be a corner case. Please understand that many
]] Philip Hands
I used to use mondo-rescue for ensuring that systems were rescue-able.
The problem is that on production systems one quite often never gets
given the chance to test if the rescue system still works, so I ended up
abandoning the use of mondo because it happened to me often
On 25.12.2011 12:12, Thomas Goirand wrote:
On 12/22/2011 07:07 PM, Russell Coker wrote:
It seems to me that wanting to have / outside LVM but /usr inside LVM is a
fairly obscure corner case.
I have about 100 servers setup this way, and my laptops as well. I really
don't see why this would be
On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote:
Debian systems without an initramfs already represent an uncommon case;
Are you sure about this? How many server systems have/need an initramfs
(think about VMs like XEN DomU)? How many of them are using the big
Debian kernel
On Sun, Dec 25, 2011 at 04:12:48PM +0800, Thomas Goirand wrote:
On 12/22/2011 07:07 PM, Russell Coker wrote:
It seems to me that wanting to have / outside LVM but /usr inside LVM is a
fairly obscure corner case.
I have about 100 servers setup this way, and my laptops as well. I really
On 2011-12-25, Stephan Seitz stse+deb...@fsing.rootsland.net wrote:
All admins I know have at least some servers with custom kernels (in the
past it was said, to build your firewall/server kernels without module
support, so that no rootkit module could be loaded).
No longer needed. See
Le samedi 24 décembre 2011 à 19:03 +0800, Paul Wise a écrit :
Apparently the reason is simply that our upstreams (who it sounds like
are predominantly driven by Redhat folks) are dropping support for /
and /usr on different partitions and that re-adding that support or
maintaining the
On Sat, 24 Dec 2011 10:17:49 +0800, Paul Wise p...@debian.org wrote:
On Sat, Dec 24, 2011 at 3:05 AM, Goswin von Brederlow wrote:
Maybe there is some misunderstanding here. I think nobody has suggested
to build a rescue initramfs on the users system tailor made for the
system.
We
1 - 100 of 152 matches
Mail list logo
