Re: deprecating /usr as a standalone filesystem?

2009-05-17 Thread Steve Langasek
On Mon, May 18, 2009 at 06:25:07AM +1000, Kel Modderman wrote:
> On Wednesday 06 May 2009 03:39:40 Steve Langasek wrote:
> > On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote:
> > > I have been told by upstream maintainers of one of my packages and by
> > > prominent developers of other distributions that supporting a standalone
> > > /usr is too much work and no other distribution worth mentioning does it
> > > (not Ubuntu, not Fedora, not SuSE).

> > This is false for Ubuntu.  Not only is it supported, but significant effort
> > was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as
> > pertains to wpasupplicant.

> Are the same changes (moving of runtime libs wpasupplicant uses to /lib)
> likely to be handed back to Debian?

That would be the goal, but of course there are more maintainers who need to
be coordinated with in the case of Debian so there's no telling how much
longer it will take to get all the changes in.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-17 Thread Kel Modderman
On Wednesday 06 May 2009 03:39:40 Steve Langasek wrote:
> On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote:
> > I have been told by upstream maintainers of one of my packages and by
> > prominent developers of other distributions that supporting a standalone
> > /usr is too much work and no other distribution worth mentioning does it
> > (not Ubuntu, not Fedora, not SuSE).
> 
> This is false for Ubuntu.  Not only is it supported, but significant effort
> was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as
> pertains to wpasupplicant.

Are the same changes (moving of runtime libs wpasupplicant uses to /lib)
likely to be handed back to Debian?

The same /usr-as-separate-mount bug is likely to strike iw and crda as well as
it did wpasupplicant.

Thanks, Kel.


Re: deprecating /usr as a standalone filesystem?

2009-05-16 Thread Faidon Liambotis
Marco d'Itri wrote:
> I have been told by upstream maintainers of one of my packages and by
> prominent developers of other distributions that supporting a standalone
> /usr is too much work and no other distribution worth mentioning does it
> (not Ubuntu, not Fedora, not SuSE).
BTW, last month Lennart Poettering began a discussion on
fedora-devel-list about deprecating /usr completely, i.e. symlinking it
to /:

https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01063.html

It seems that most of the arguments on that thread against that change
were "but we won't be able to mount /usr separately that way!". I'm no
Fedora expert, but it sounds like it is actually a supported
configuration in Fedora.

Regards,
Faidon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Gabor Gombas
On Fri, May 15, 2009 at 07:12:59AM +0200, Goswin von Brederlow wrote:

> There is absolutely no reason why you can not mount a filesystem over
> /root later in the boot process. I agree that /root should/must exist
> at all time so one can login when for example fsck fails.

No, you must be able to log in even if /root have ended up in
/lost+found. Anything that relies on the existence of /root is bogus
and should be fixed. Note 17 in the FHS (that Giaocomo already quoted)
specifies how the system should handle the case when root's home cannot
be located - it must just work.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Goswin von Brederlow
Manoj Srivastava  writes:

> Sure. I can hack things so that I have a writable home directory
>  for root while having a read only /. But then it is incorrect to state
>  that it "works out of the box".
>
> manoj

If you have a read-only / you need to have /var and /home as seperate
filesystem. Requireing to have /root seperate as well is no
different. That is still out of the box for me.

Also I don't consider writing to /root normal. "Works out of the box
for normal operations" if you will.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Goswin von Brederlow
"Giacomo A. Catenazzi"  writes:

> Gabor Gombas wrote:
>> On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote:
>>
>>> No, /root cannot be a separate filesystem.
>>> /root is part of very basic system, and it is required for super user
>>> when he/she is restoring the systems or doing some kind of administration
>>> (e.g. moving filesystems, etc.).
>>
>> Obviously not. If fscking "/" fails then "/" _will_ be read-only and you
>> _must_ be able to fix it without being able to write under /root, so any
>> system restoration task must work without /root being writeable.
>>
>> If you want to write to /root, then _make_ it writable! That's why you
>> are the system administrator after all. If you want "/" to be read-only,
>> then move /root to some other filesystem. If you want /root to be on the
>> same filesystem as "/", then do not make "/" read-only. Really, this is a
>> "Doctor, it hurts if I shoot myself in the foot - Don't do it, then"
>> kind of situation...
>
> I totally agree that / (thus /root) could be read-only.
>
> I pointed out to you that /root is required to be in the same
> filesystem as / (FHS) and I gave you the rationale.
>
> I really prefer to allow / and /root read-only than to allow
> /root in a different filesystem (user could do also this choice,
> but outside debian support cases).
>
> ciao
>   cate

There is absolutely no reason why you can not mount a filesystem over
/root later in the boot process. I agree that /root should/must exist
at all time so one can login when for example fsck fails. But that
works perfectly fine with /root being an empty directory on / and
later having a filesystem mounted there.

So I would be against /home/root, as one would have to create that on
/ before /home gets mounted so it is always available. That kind of
shadowed directory is harder to create for DI and wouldn't show up in
a backup and be missing after a restore. I would rather bind mount
/home/root to /root to make /root read-write.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Manoj Srivastava
On Thu, May 14 2009, Gabor Gombas wrote:

> On Wed, May 13, 2009 at 12:38:45PM -0500, Manoj Srivastava wrote:
>
>> it is the principle of the thing. /root is the home directory
>>  for the  root user.  Home directories are mutable, programs may store
>>  configuration files there, as may the user, by themselves. The root
>>  user should not be more constrained than other users on the machine are;
>>  making wirking as root irritating, less customizable, and harder does
>>  not help the end user admin any.
>> 
>> Ideally, we should map /root somewhere persistent, writable, and
>>  also a location available in single user mode; and there are few
>>  pleasing solutions that meet that criteria; though less than perfect
>>  solutions exist.
>
> I fail to see how root is different to any other random user in this
> regard. If you want / to be read-only, then you should ensure that /home
> points to something writable. The same thing holds for /root. You can
> make /home and /root to be separate filesystems, or bind mounts or
> symlinks pointing to a writable location. If you can handle /home today
> then you can also handle /root exactly the same way.
>
> So the only thing to do is ensure that whatever code/documentation talks
> about /home should also talk about/handle /root as well. In fact, if /
> is supposed to be read-only, then I see absolutely no reason to use
> /root instead of /home/root. Maybe we need an option in the installer to
> set root's HOME directory to /home/root instead of /root?

Sure. I can hack things so that I have a writable home directory
 for root while having a read only /. But then it is incorrect to state
 that it "works out of the box".

manoj
-- 
The difference between a Miracle and a Fact is exactly the difference
between a mermaid and a seal. -- Mark Twain
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Steve Langasek
On Thu, May 14, 2009 at 02:27:52PM +0100, Klaus Ethgen wrote:

> There might also software very early in the boot process that need a
> writable root-$HOME.

Nonsense.  Any such software needs to be beaten severely.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Giacomo A. Catenazzi

Gabor Gombas wrote:

On Thu, May 14, 2009 at 04:21:53PM +0200, Giacomo A. Catenazzi wrote:


I totally agree that / (thus /root) could be read-only.

I pointed out to you that /root is required to be in the same filesystem as / 
(FHS) and I gave
you the rationale.


What's the FHS says is a little different:

/root : Home directory for the root user (optional)

Purpose

The root account's home directory may be determined by developer or local 
preference, but this is
the recommended default location.

So the presence of /root is not required and root's home directory can be set 
to /home/root by
the installer if a read-only "/" is wanted.


Yes, you are right, and the "optional" is very nice!
I was confusing with the following note (and maybe an older version):

"""
If the home directory of the root account is not stored on the root partition 
it will be necessary
to make certain it will default to / if it can not be located.
"""

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Gabor Gombas
On Thu, May 14, 2009 at 04:21:53PM +0200, Giacomo A. Catenazzi wrote:

> I totally agree that / (thus /root) could be read-only.
>
> I pointed out to you that /root is required to be in the same
> filesystem as / (FHS) and I gave you the rationale.

What's the FHS says is a little different:

/root : Home directory for the root user (optional)

Purpose

The root account's home directory may be determined by developer
or local preference, but this is the recommended default
location.

So the presence of /root is not required and root's home directory can
be set to /home/root by the installer if a read-only "/" is wanted.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Giacomo A. Catenazzi

Gabor Gombas wrote:

On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote:


No, /root cannot be a separate filesystem.
/root is part of very basic system, and it is required for super user
when he/she is restoring the systems or doing some kind of administration
(e.g. moving filesystems, etc.).


Obviously not. If fscking "/" fails then "/" _will_ be read-only and you
_must_ be able to fix it without being able to write under /root, so any
system restoration task must work without /root being writeable.

If you want to write to /root, then _make_ it writable! That's why you
are the system administrator after all. If you want "/" to be read-only,
then move /root to some other filesystem. If you want /root to be on the
same filesystem as "/", then do not make "/" read-only. Really, this is a
"Doctor, it hurts if I shoot myself in the foot - Don't do it, then"
kind of situation...


I totally agree that / (thus /root) could be read-only.

I pointed out to you that /root is required to be in the same
filesystem as / (FHS) and I gave you the rationale.

I really prefer to allow / and /root read-only than to allow
/root in a different filesystem (user could do also this choice,
but outside debian support cases).

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Giacomo A. Catenazzi

Roger Leigh wrote:

On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote:

Gabor Gombas wrote:

On Wed, May 13, 2009 at 12:38:45PM -0500, Manoj Srivastava wrote:


it is the principle of the thing. /root is the home directory
 for the  root user.  Home directories are mutable, programs may store
 configuration files there, as may the user, by themselves. The root
 user should not be more constrained than other users on the machine are;
 making wirking as root irritating, less customizable, and harder does
 not help the end user admin any.

Ideally, we should map /root somewhere persistent, writable, and
 also a location available in single user mode; and there are few
 pleasing solutions that meet that criteria; though less than perfect
 solutions exist.

I fail to see how root is different to any other random user in this
regard. If you want / to be read-only, then you should ensure that /home
points to something writable. The same thing holds for /root. You can
make /home and /root to be separate filesystems, or bind mounts or
symlinks pointing to a writable location. If you can handle /home today
then you can also handle /root exactly the same way.

No, /root cannot be a separate filesystem.
/root is part of very basic system, and it is required for super user
when he/she is restoring the systems or doing some kind of administration
(e.g. moving filesystems, etc.).


Why do these tasks require a writable (or even present) /root?


Interesting question. I think none, but:
- FHS
- someone pointed they would like .bash_history (but this is a sysadmin
  preference),
- On my system I've data from aptitude, vim, less, mc , but I think
  I these program can works also without root (BTW all in /usr)
- mysql puts admin password in /root , so maybe it is required to
  to mysql maintenance (I expect: existence, but shoudl be ok for read-only)
- ssh/scp: not sure, (but they are in /usr)

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Gabor Gombas
On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote:

> No, /root cannot be a separate filesystem.
> /root is part of very basic system, and it is required for super user
> when he/she is restoring the systems or doing some kind of administration
> (e.g. moving filesystems, etc.).

Obviously not. If fscking "/" fails then "/" _will_ be read-only and you
_must_ be able to fix it without being able to write under /root, so any
system restoration task must work without /root being writeable.

If you want to write to /root, then _make_ it writable! That's why you
are the system administrator after all. If you want "/" to be read-only,
then move /root to some other filesystem. If you want /root to be on the
same filesystem as "/", then do not make "/" read-only. Really, this is a
"Doctor, it hurts if I shoot myself in the foot - Don't do it, then"
kind of situation...

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Roger Leigh
On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote:
> Gabor Gombas wrote:
>> On Wed, May 13, 2009 at 12:38:45PM -0500, Manoj Srivastava wrote:
>>
>>> it is the principle of the thing. /root is the home directory
>>>  for the  root user.  Home directories are mutable, programs may store
>>>  configuration files there, as may the user, by themselves. The root
>>>  user should not be more constrained than other users on the machine are;
>>>  making wirking as root irritating, less customizable, and harder does
>>>  not help the end user admin any.
>>>
>>> Ideally, we should map /root somewhere persistent, writable, and
>>>  also a location available in single user mode; and there are few
>>>  pleasing solutions that meet that criteria; though less than perfect
>>>  solutions exist.
>>
>> I fail to see how root is different to any other random user in this
>> regard. If you want / to be read-only, then you should ensure that /home
>> points to something writable. The same thing holds for /root. You can
>> make /home and /root to be separate filesystems, or bind mounts or
>> symlinks pointing to a writable location. If you can handle /home today
>> then you can also handle /root exactly the same way.
>
> No, /root cannot be a separate filesystem.
> /root is part of very basic system, and it is required for super user
> when he/she is restoring the systems or doing some kind of administration
> (e.g. moving filesystems, etc.).

Why do these tasks require a writable (or even present) /root?


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Klaus Ethgen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Do den 14. Mai 2009 um 14:01 schrieb Gabor Gombas:
> I fail to see how root is different to any other random user in this
> regard. If you want / to be read-only, then you should ensure that /home
> points to something writable. The same thing holds for /root.

That is not always true. root _is_ special as it might be needed in
single user mode or in emergency mode. There might also software very
early in the boot process that need a writable root-$HOME.

Regards
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen 
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBSgwcWJ+OKpjRpO3lAQre9wf/XQ8A35N0aoaGi0D05c5qVtFbG7fMeI9t
9HOhV4YVTJT0QBkuJGnDBHvx8ZXCMggjjY/xRXe4k8XetwAbg2cm2ZAk4L8KOT5B
vuwFxalyjmtt9XF6yegTPo5PfJtyPKRci8VqgeEzkTte0DYrlEyzMiA8rK+IdImz
xm3rv7dpZ+AT1hjPwSHqWS0LVdZ9wbjFoWwYLaIikgJY9J018NHjeFNGTXvv9IeS
LZ/JGa6QT9zvakUQlWUQDpctivSZbyE3mvDWKHIY0NxWUXiASw9hccbGqluS011M
KW+6Y3j5F3fnZGkeVk/iWPCoRq5Pb9+Dm+kqI9mr09/0ciu/h5fU7A==
=jKwZ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Giacomo A. Catenazzi

Gabor Gombas wrote:

On Wed, May 13, 2009 at 12:38:45PM -0500, Manoj Srivastava wrote:


it is the principle of the thing. /root is the home directory
 for the  root user.  Home directories are mutable, programs may store
 configuration files there, as may the user, by themselves. The root
 user should not be more constrained than other users on the machine are;
 making wirking as root irritating, less customizable, and harder does
 not help the end user admin any.

Ideally, we should map /root somewhere persistent, writable, and
 also a location available in single user mode; and there are few
 pleasing solutions that meet that criteria; though less than perfect
 solutions exist.


I fail to see how root is different to any other random user in this
regard. If you want / to be read-only, then you should ensure that /home
points to something writable. The same thing holds for /root. You can
make /home and /root to be separate filesystems, or bind mounts or
symlinks pointing to a writable location. If you can handle /home today
then you can also handle /root exactly the same way.


No, /root cannot be a separate filesystem.
/root is part of very basic system, and it is required for super user
when he/she is restoring the systems or doing some kind of administration
(e.g. moving filesystems, etc.).
Now with live CDw this is less relevant then in the past.

OTOH usually sulogin will login (as super user) when / is still
read-only, so basic tools (in /bin and /sbin) should works also
on read-only /root.

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-14 Thread Gabor Gombas
On Wed, May 13, 2009 at 12:38:45PM -0500, Manoj Srivastava wrote:

> it is the principle of the thing. /root is the home directory
>  for the  root user.  Home directories are mutable, programs may store
>  configuration files there, as may the user, by themselves. The root
>  user should not be more constrained than other users on the machine are;
>  making wirking as root irritating, less customizable, and harder does
>  not help the end user admin any.
> 
> Ideally, we should map /root somewhere persistent, writable, and
>  also a location available in single user mode; and there are few
>  pleasing solutions that meet that criteria; though less than perfect
>  solutions exist.

I fail to see how root is different to any other random user in this
regard. If you want / to be read-only, then you should ensure that /home
points to something writable. The same thing holds for /root. You can
make /home and /root to be separate filesystems, or bind mounts or
symlinks pointing to a writable location. If you can handle /home today
then you can also handle /root exactly the same way.

So the only thing to do is ensure that whatever code/documentation talks
about /home should also talk about/handle /root as well. In fact, if /
is supposed to be read-only, then I see absolutely no reason to use
/root instead of /home/root. Maybe we need an option in the installer to
set root's HOME directory to /home/root instead of /root?

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-13 Thread Goswin von Brederlow
Manoj Srivastava  writes:

> On Tue, May 12 2009, Goswin von Brederlow wrote:
>
>
>>>  I don't know if there are more blocker. Oh, and /root is a home
>>>  directory; unless we move that,  a read only / would affect root
>>>  negatively.
>>
>> How so? Only thing I can think of is the bash history. But it is not
>> like we force a read-only /. That is a choice.
>
> it is the principle of the thing. /root is the home directory
>  for the  root user.  Home directories are mutable, programs may store
>  configuration files there, as may the user, by themselves. The root
>  user should not be more constrained than other users on the machine are;
>  making wirking as root irritating, less customizable, and harder does
>  not help the end user admin any.
>
> Ideally, we should map /root somewhere persistent, writable, and
>  also a location available in single user mode; and there are few
>  pleasing solutions that meet that criteria; though less than perfect
>  solutions exist.
>
> manoj

You can always (bind) mount something on /root. If you want read-only
/ but can't live with read-only /root then that is the way to
go. Alternatively you can change roots hoomedir or create a toor user
with id 0 and /home/toor or something.

I for my part don't work as root making use of sudo where
required. Never felt a great need to use /root.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-13 Thread Manoj Srivastava
On Tue, May 12 2009, Goswin von Brederlow wrote:


>>  I don't know if there are more blocker. Oh, and /root is a home
>>  directory; unless we move that,  a read only / would affect root
>>  negatively.
>
> How so? Only thing I can think of is the bash history. But it is not
> like we force a read-only /. That is a choice.

it is the principle of the thing. /root is the home directory
 for the  root user.  Home directories are mutable, programs may store
 configuration files there, as may the user, by themselves. The root
 user should not be more constrained than other users on the machine are;
 making wirking as root irritating, less customizable, and harder does
 not help the end user admin any.

Ideally, we should map /root somewhere persistent, writable, and
 also a location available in single user mode; and there are few
 pleasing solutions that meet that criteria; though less than perfect
 solutions exist.

manoj
-- 
Success is relative: It is what we can make of the mess we have made of
things. T.S. Eliot, "The Family Reunion"
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-12 Thread Goswin von Brederlow
Manoj Srivastava  writes:

> On Mon, May 11 2009, Goswin von Brederlow wrote:
>
>> Henrique de Moraes Holschuh  writes:
>>
>>> On Mon, 11 May 2009, Goswin von Brederlow wrote:
 > A separate /usr *is* the way to go if you don't want any writes in
 > that filesystem 99.9% of the time (i.e. when you're not doing an
 > upgrade).
 
 A read-only / does the trick just as well. And if you don't want
 writes to /usr you probably don't want writes to /bin or /sbin
 either. So read-only / is really the way to go. Not a strong argument
 for a seperate /usr.
>>>
>>> No, RO / is a lot more difficult to pull off (remember: some of us don't
>>> want initrds), while RO /usr is really just a three-char change on fstab
>>> (and if you want apt to remount things automatically, two lines in a config
>>> file).
>>
>> Why would you need an initrd for a read-only /?
>>
>> A read-only / should work out of the box just like a read-only /usr. I
>
> Except it does not.

I said should. :) Last I set one up it still needed some assembly but
that is being worked on. It is certainly within reach for Squeeze.

>> haven't installed a fresh one in a long while though so if you know of
>> problems speak up so bugs can be filed and packages can be fixed.
>
> There is the /etc/mtab issue, and then there are things like
>  resolvconf that try to scribble in /etc.  I have not tried recently, so

The /etc/mtab problem is finaly solved for all cases (like quota
users) with kernel >2.6.26. There is a bug report about it and that is
hopefully soon to be made to work out of the box. No assembly required
then anymore.

Resolvconf uses /lib/init/rw so that isn't a stoper anymore.

ifup/down has some code for read-only / in it too.

>  I don't know if there are more blocker. Oh, and /root is a home
>  directory; unless we move that,  a read only / would affect root
>  negatively.

How so? Only thing I can think of is the bash history. But it is not
like we force a read-only /. That is a choice.

> A read-only / would be nice, but unless you try it on a real
>  box, I don't think you assert it should be working out of the box.

I'm sure there are some packages out there that still don't work right
with read-only /. But none I use and thuse none I know about. As far
as I know the /etc/mtab issue is the last pending thing.

> manoj

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-11 Thread Goswin von Brederlow
Roger Leigh  writes:

> On Mon, May 11, 2009 at 09:59:36AM -0300, Henrique de Moraes Holschuh wrote:
>> On Mon, 11 May 2009, Goswin von Brederlow wrote:
>> > A read-only / should work out of the box just like a read-only /usr. I
>> > haven't installed a fresh one in a long while though so if you know of
>> > problems speak up so bugs can be filed and packages can be fixed.
>> 
>> Last time I tried it, /etc was a problem.  I'd have to retry doing it, and
>> frankly, I do not have the time to muck with that right now.
>
> #494001 is the main blocker.  It's just waiting for the patch to be
> applied AFAICT.

Ok, that one doesn't work out of the box but is easily rectified by
the admin. But it has been known a long time and is finaly fixable.

Should have said unknown bugs. :)

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-11 Thread Mike Hommey
On Mon, May 11, 2009 at 04:38:59PM +0100, Roger Leigh  
wrote:
> There's a patch for /etc/mtab elimination; it's totally unneeded nowadays.

More than unneeded, it is absolutely irrelevant when using mount namespaces.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-11 Thread Roger Leigh
On Mon, May 11, 2009 at 09:20:44AM -0500, Manoj Srivastava wrote:
> On Mon, May 11 2009, Goswin von Brederlow wrote:
> 
> > Henrique de Moraes Holschuh  writes:
> >
> >> On Mon, 11 May 2009, Goswin von Brederlow wrote:
> >>> > A separate /usr *is* the way to go if you don't want any writes in
> >>> > that filesystem 99.9% of the time (i.e. when you're not doing an
> >>> > upgrade).
> >>> 
> >>> A read-only / does the trick just as well. And if you don't want
> >>> writes to /usr you probably don't want writes to /bin or /sbin
> >>> either. So read-only / is really the way to go. Not a strong argument
> >>> for a seperate /usr.
> >>
> >> No, RO / is a lot more difficult to pull off (remember: some of us don't
> >> want initrds), while RO /usr is really just a three-char change on fstab
> >> (and if you want apt to remount things automatically, two lines in a config
> >> file).
> >
> > Why would you need an initrd for a read-only /?
> >
> > A read-only / should work out of the box just like a read-only /usr. I
> 
> Except it does not.
> 
> > haven't installed a fresh one in a long while though so if you know of
> > problems speak up so bugs can be filed and packages can be fixed.
> 
> There is the /etc/mtab issue, and then there are things like
>  resolvconf that try to scribble in /etc.  I have not tried recently, so
>  I don't know if there are more blocker.

resolvconf uses /lib/init/rw nowadays, so no /etc writing is needed.

There's a patch for /etc/mtab elimination; it's totally unneeded nowadays.

There may be a few other minor issues, but a read-only root is well in
reach for Squeeze if people try it out and report any remaining cases.


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-11 Thread Manoj Srivastava
On Mon, May 11 2009, Goswin von Brederlow wrote:

> Henrique de Moraes Holschuh  writes:
>
>> On Mon, 11 May 2009, Goswin von Brederlow wrote:
>>> > A separate /usr *is* the way to go if you don't want any writes in
>>> > that filesystem 99.9% of the time (i.e. when you're not doing an
>>> > upgrade).
>>> 
>>> A read-only / does the trick just as well. And if you don't want
>>> writes to /usr you probably don't want writes to /bin or /sbin
>>> either. So read-only / is really the way to go. Not a strong argument
>>> for a seperate /usr.
>>
>> No, RO / is a lot more difficult to pull off (remember: some of us don't
>> want initrds), while RO /usr is really just a three-char change on fstab
>> (and if you want apt to remount things automatically, two lines in a config
>> file).
>
> Why would you need an initrd for a read-only /?
>
> A read-only / should work out of the box just like a read-only /usr. I

Except it does not.

> haven't installed a fresh one in a long while though so if you know of
> problems speak up so bugs can be filed and packages can be fixed.

There is the /etc/mtab issue, and then there are things like
 resolvconf that try to scribble in /etc.  I have not tried recently, so
 I don't know if there are more blocker. Oh, and /root is a home
 directory; unless we move that,  a read only / would affect root
 negatively.

A read-only / would be nice, but unless you try it on a real
 box, I don't think you assert it should be working out of the box.

manoj

-- 
"Vendi, vidi, parenthesi" -- I came, I saw, I programmed in Lisp!" Dave
W. Kimball
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-11 Thread Roger Leigh
On Mon, May 11, 2009 at 09:59:36AM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 11 May 2009, Goswin von Brederlow wrote:
> > A read-only / should work out of the box just like a read-only /usr. I
> > haven't installed a fresh one in a long while though so if you know of
> > problems speak up so bugs can be filed and packages can be fixed.
> 
> Last time I tried it, /etc was a problem.  I'd have to retry doing it, and
> frankly, I do not have the time to muck with that right now.

#494001 is the main blocker.  It's just waiting for the patch to be
applied AFAICT.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-11 Thread Henrique de Moraes Holschuh
On Mon, 11 May 2009, Goswin von Brederlow wrote:
> A read-only / should work out of the box just like a read-only /usr. I
> haven't installed a fresh one in a long while though so if you know of
> problems speak up so bugs can be filed and packages can be fixed.

Last time I tried it, /etc was a problem.  I'd have to retry doing it, and
frankly, I do not have the time to muck with that right now.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-11 Thread Goswin von Brederlow
Henrique de Moraes Holschuh  writes:

> On Mon, 11 May 2009, Goswin von Brederlow wrote:
>> > A separate /usr *is* the way to go if you don't want any writes in
>> > that filesystem 99.9% of the time (i.e. when you're not doing an
>> > upgrade).
>> 
>> A read-only / does the trick just as well. And if you don't want
>> writes to /usr you probably don't want writes to /bin or /sbin
>> either. So read-only / is really the way to go. Not a strong argument
>> for a seperate /usr.
>
> No, RO / is a lot more difficult to pull off (remember: some of us don't
> want initrds), while RO /usr is really just a three-char change on fstab
> (and if you want apt to remount things automatically, two lines in a config
> file).

Why would you need an initrd for a read-only /?

A read-only / should work out of the box just like a read-only /usr. I
haven't installed a fresh one in a long while though so if you know of
problems speak up so bugs can be filed and packages can be fixed.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-11 Thread Henrique de Moraes Holschuh
On Mon, 11 May 2009, Goswin von Brederlow wrote:
> > A separate /usr *is* the way to go if you don't want any writes in
> > that filesystem 99.9% of the time (i.e. when you're not doing an
> > upgrade).
> 
> A read-only / does the trick just as well. And if you don't want
> writes to /usr you probably don't want writes to /bin or /sbin
> either. So read-only / is really the way to go. Not a strong argument
> for a seperate /usr.

No, RO / is a lot more difficult to pull off (remember: some of us don't
want initrds), while RO /usr is really just a three-char change on fstab
(and if you want apt to remount things automatically, two lines in a config
file).

> The other mount options like nodev or having a different filesystem
> type for /usr are stronger reasons.

They're extra reasons, and strong ones at that, yes.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-10 Thread Roger Leigh
On Mon, May 11, 2009 at 12:32:40AM -0400, Daniel Dickinson wrote:
> > On Tue, 5 May 2009 17:36:02 +0200
> > m...@linux.it (Marco d'Itri) wrote:
> > 
> > > I have been told by upstream maintainers of one of my packages and
> > > by prominent developers of other distributions that supporting a
> > > standalone /usr is too much work and no other distribution worth
> > > mentioning does it (not Ubuntu, not Fedora, not SuSE).
> > > 
> > > I know that Debian supports this, but I also know that maintaning
> > > forever large changes to packages for no real gain sucks.
> > > 
> > > So, does anybody still see reasons to continue supporting a
> > > standalone /usr?
> 
> You can lvm resize a standalone /usr by booting single user (I've done
> it when my /usr got too small).

You know you can do all that online nowadays?  Just lvmresize and
resize2fs (or the equivalent) while it's mounted; no single user
mode required.


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-10 Thread Daniel Dickinson
> On Tue, 5 May 2009 17:36:02 +0200
> m...@linux.it (Marco d'Itri) wrote:
> 
> > I have been told by upstream maintainers of one of my packages and
> > by prominent developers of other distributions that supporting a
> > standalone /usr is too much work and no other distribution worth
> > mentioning does it (not Ubuntu, not Fedora, not SuSE).
> > 
> > I know that Debian supports this, but I also know that maintaning
> > forever large changes to packages for no real gain sucks.
> > 
> > So, does anybody still see reasons to continue supporting a
> > standalone /usr?

You can lvm resize a standalone /usr by booting single user (I've done
it when my /usr got too small).

In addition getting rid of a standalone /usr will break existing
configurations.  It would break mine, for instance, because I
partitioned my hard drive based on the knowledge that /usr could be a
separate filesystem.

What about nfs-served /usr?

Regards,

Daniel

-- 
And that's my crabbing done for the day.  Got it out of the way early, 
now I have the rest of the afternoon to sniff fragrant tea-roses or 
strangle cute bunnies or something.   -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C  http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com


signature.asc
Description: PGP signature


Re: deprecating /usr as a standalone filesystem?

2009-05-10 Thread Goswin von Brederlow
Henrique de Moraes Holschuh  writes:

> On Fri, 08 May 2009, David Weinehall wrote:
>> > No. But we do leave /usr read-only the rest of the time, which
>> >  is often 99.999% of the time. A separate /usr is required for this.
>> 
>> Uhm, no?
>> 
>> mount --bind /usr /usr
>
> First, you'd need a RO bind mount (yes, it exists, but your command
> doesn't do it).  Second, the filesystem is still RW, so it gains you
> very little as far as data safety goes.
>
> A separate /usr *is* the way to go if you don't want any writes in
> that filesystem 99.9% of the time (i.e. when you're not doing an
> upgrade).

A read-only / does the trick just as well. And if you don't want
writes to /usr you probably don't want writes to /bin or /sbin
either. So read-only / is really the way to go. Not a strong argument
for a seperate /usr.

The other mount options like nodev or having a different filesystem
type for /usr are stronger reasons.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-10 Thread Harald Braumann
On Tue, 5 May 2009 17:36:02 +0200
m...@linux.it (Marco d'Itri) wrote:

> I have been told by upstream maintainers of one of my packages and by
> prominent developers of other distributions that supporting a
> standalone /usr is too much work and no other distribution worth
> mentioning does it (not Ubuntu, not Fedora, not SuSE).
> 
> I know that Debian supports this, but I also know that maintaning
> forever large changes to packages for no real gain sucks.
> 
> So, does anybody still see reasons to continue supporting a standalone
> /usr?
> If you do, please provide a detailed real-world use case.
> A partial list of invalid reasons is:
> - "I heard that this was popular in 1998"
> - "it's a longstanding tradition to support this"
> - "it's really useful on my 386 SX with a 40 MB hard disk"
> 

This thread has been going on for quite some time without any insight
into what the actual problem with a separate /usr might be. Could you
please elaborate?

The only issues I can think of are hard links and atomic renames.
Though I can't think of any use-case where you would need this
between /usr and some place outside /usr.

Cheers,
harry


signature.asc
Description: PGP signature


Re: deprecating /usr as a standalone filesystem?

2009-05-10 Thread David Weinehall
On Sun, May 10, 2009 at 08:51:33AM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 08 May 2009, David Weinehall wrote:
> > > No. But we do leave /usr read-only the rest of the time, which
> > >  is often 99.999% of the time. A separate /usr is required for this.
> > 
> > Uhm, no?
> > 
> > mount --bind /usr /usr
> 
> First, you'd need a RO bind mount (yes, it exists, but your command
> doesn't do it).  Second, the filesystem is still RW, so it gains you
> very little as far as data safety goes.

That's because you neatly trimmed off the rest of my message, which was:

> > Should do the trick (the same mount -o remount,rw / remount,ro then
> > applies).  all thanks to the magic of subtrees :)

> A separate /usr *is* the way to go if you don't want any writes in
> that filesystem 99.9% of the time (i.e. when you're not doing an
> upgrade).

I'm not opposing this, and I definitely don't support Marco's idea.
I just pointed out that a separate filesystem isn't required to
make a mountpoint read-only.


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-10 Thread Henrique de Moraes Holschuh
On Fri, 08 May 2009, David Weinehall wrote:
> > No. But we do leave /usr read-only the rest of the time, which
> >  is often 99.999% of the time. A separate /usr is required for this.
> 
> Uhm, no?
> 
> mount --bind /usr /usr

First, you'd need a RO bind mount (yes, it exists, but your command
doesn't do it).  Second, the filesystem is still RW, so it gains you
very little as far as data safety goes.

A separate /usr *is* the way to go if you don't want any writes in
that filesystem 99.9% of the time (i.e. when you're not doing an
upgrade).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-08 Thread Goswin von Brederlow
Stefano Zacchiroli  writes:

> On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote:
>> > So, does anybody still see reasons to continue supporting a standalone
>> > /usr?
>> There had been lots of responses to that.
>
> Yes, the most repeated argument has been mount /usr via NFS.
> Unfortunately, nobody yet explained how do they update the resulting
> cluster of machines.

On the NFS server you install a full system in a chroot (or run it as
xen/kvm/... instace for maintainance).

On clients during boot you run

rsync -avPSHx --exclude-from=host-files server:chroot/ /

The host-files lists some files in /etc/ and /var and also /usr and
/home and other directories you NFS mount.

> Of course the problem is that if you update on the NFS server, then
> related /etc and /var files [1] will not get updated on the NFS client
> machines and you need to propagate changes there. I see as quite
> pointless to use "let's export /usr via NFS" as an argument, if Debian
> does not provide a way to make that setup tenable.

ACK. There is really not much point in having / local. It is easy
enough to use nfs-root and overlay a host specific /etc and
/var. People might just not be used to it.

Networking is not a good argument why /usr must be kept
seperate. Stick to the other reasons mentioned.

> ACK on your second clarification request, though.
>
> Cheers.
>
> [1] Or anything else actually, given that maintainer scripts can
> affect basically all the filesystem.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem? [386 support]

2009-05-08 Thread Goswin von Brederlow
Josselin Mouette  writes:

> Le mardi 05 mai 2009 à 23:38 +0200, Frank Lin PIAT a écrit :
>> Interesting. I thought 386 wasn't supported anymore (?)
>
> AFAIK the kernel is able to emulate a 486 when running on a 386.

Afaik only when properly patched to do so and including glibc patches.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-08 Thread Goswin von Brederlow
Giacomo Catenazzi  writes:

> Roger Leigh wrote:
>> On Tue, May 05, 2009 at 05:41:06PM +0200, Stéphane Glondu wrote:
>>> Marco d'Itri a écrit :
 I know that Debian supports this, but I also know that maintaning
 forever large changes to packages for no real gain sucks.
 A partial list of invalid reasons is: [...]
>>> How about: "my /usr is shared by many machines over NFS"?
>> 
>> That might have been a "traditional" reason for a shared /usr.
>> However, the package manager can't cope with this setup since
>> you have some components of a package installed locally and
>> some remotely for all systems using the "shared" part.  It's
>> an impossible situation to actually cater for in real life.
>> Has anyone ever actually *done* this?
>
> So why we created /usr/share (and moved documentation) ?

.oO(preparing for Multiarch support :)

> I see a lot of parallel installed system, so in this case
> I see no problem on sharing /usr.
> [BTW one of the most important conference is not LISA, about
> such configurations?]
>
> But also I don't think it is a problem sharing usr
> on multiple system with multiple configurations.
>
> On non public working stations, one doesn't run randomly
> programs. If I installed mysql-server on a system,
> it will work on such system, but if I install on
> an other system, it work also on the other system,
> occupying only one instance.
>
> I don't see problem from package management
> (also because we have a nullpotent dpkg), so
> we can upgrade from multiple system without problems.

apt-get install libmysqlclient16
apt-get remove --purge libmysqlclient16

and suddenly your other system has a broken mysql-server.

With your setup you can only install packages savely but not remove
them. Which one can decide to live with.

>> Looking at GNU/Hurd, /usr is a symlink to /.  If we were to make
>> /usr non-separable, maybe this would be the way to go.
>
> or plan9, which bind mount all /*/bin into the main /bin.
> I can live with such solution, but please allow us to use /usr
> in a different (maybe shared) partition.
>
> ciao
>   cate

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-08 Thread Goswin von Brederlow
Roger Leigh  writes:

> On Tue, May 05, 2009 at 06:49:47PM +0200, Josselin Mouette wrote:
>> Le mardi 05 mai 2009 à 17:24 +0100, Roger Leigh a écrit :
>> > That might have been a "traditional" reason for a shared /usr.
>> > However, the package manager can't cope with this setup since
>> > you have some components of a package installed locally and
>> > some remotely for all systems using the "shared" part.  It's
>> > an impossible situation to actually cater for in real life.
>> > Has anyone ever actually *done* this?
>> 
>> Of course, you just need to think the image you actually update as a
>> master image, after which it is replicated by any means necessary (be it
>> systemimager or NFS).
>
> Sure, but you effectively only have "one" master image.  You don't
> have multiple users of /usr with differing /etc or /var.  They are
> all kept in sync.  This kind of makes /usr redundant since it is
> "sharable" but only among identical systems or else you will run
> into problems.

The important part would be that a small / is replicated across all
hosts. Possibly automatically on boot whenever it changed. The large
/usr on the other hand is exported via NFS. This keeps the amount of
data being replicated small.

>> As for NFS, I’d use root NFS instead of complicating my life with two
>> different methods for / and /usr, but I guess some are doing it this
>> way.
>
> On the compute cluster I helped set up for biological modelling, we
> opted to use Debian Live images on the cluster.  It IIRC NFS mounts
> a read-only cramfs filesystem and uses aufs on top of that.  There's
> just the one big filesystem (plus some site-specific mounts for
> shared data and a big scratch area all the nodes can access).  We
> certainly saw no point in making just /usr mountable since you need
> a matching rootfs to accompany it.

I have a setup with unionfs-fuse for xen/kvm instances here. I have
one master tree that every instance mounts read-only and unionfs-fuse
overlays a read-write branch from server:/srv/rw//.

But just like you I don't need a seperate /usr for that.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-08 Thread Goswin von Brederlow
m...@linux.it (Marco d'Itri) writes:

> I have been told by upstream maintainers of one of my packages and by
> prominent developers of other distributions that supporting a standalone
> /usr is too much work and no other distribution worth mentioning does it
> (not Ubuntu, not Fedora, not SuSE).
>
> I know that Debian supports this, but I also know that maintaning
> forever large changes to packages for no real gain sucks.
>
> So, does anybody still see reasons to continue supporting a standalone
> /usr?
> If you do, please provide a detailed real-world use case.
> A partial list of invalid reasons is:
> - "I heard that this was popular in 1998"
> - "it's a longstanding tradition to support this"
> - "it's really useful on my 386 SX with a 40 MB hard disk"
>
> -- 
> ciao,
> Marco

Home case:

/ is a small raid1 that is directly booted into without initramfs
/usr is on lvm on raid5

Without a seperate /usr this would require the use of an initramfs and
seperate /boot partition or much more space.


Work case:

/ is an initramfs
/usr is shared over network for many hosts


Useability reasons:

- If fsck repairs anything while checking / the system has to
  reboot. All other filesystems can just continue. By splitting / and
  /usr there is less of a chance of / needing repair saving the reboot.

- Fsck for / is run first and then other filesystems can run in parallel.

- Less chance of filesystem corruption on / if /usr is another
  filesystem. That also means I can still boot even when /usr is
  damaged and then try to repair it.

- / is small and relatively constant while /usr grows all the
  time. With / outside LVM it can be booted directly and /usr inside
  LVM allows easy resize when more space is needed.

- / contains data that might need to be encrypted (/etc) while /usr
  can be left plain for more speed/less cpu usage.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-08 Thread Brett Parker
On 08 May 14:35, Peter Palfrader wrote:
> On Fri, 08 May 2009, David Weinehall wrote:
> 
> > On Thu, May 07, 2009 at 07:27:08PM -0500, Manoj Srivastava wrote:
> > > No. But we do leave /usr read-only the rest of the time, which
> > >  is often 99.999% of the time. A separate /usr is required for this.
> > 
> > Uhm, no?
> > 
> > mount --bind /usr /usr
> > 
> > Should do the trick (the same mount -o remount,rw / remount,ro then
> > applies).  all thanks to the magic of subtrees :)
> 
> Yeah.  Right.
> 
> wea...@intrepid:~/tmp$ mkdir foo
> wea...@intrepid:~/tmp$ touch foo/bar
> wea...@intrepid:~/tmp$ sudo mount -o bind,ro foo foo
> wea...@intrepid:~/tmp$ touch foo/baz
> wea...@intrepid:~/tmp$ 
> 
> bind mounts don't do ro.

http://lwn.net/Articles/281157/

As of 2.6.26 it's possible, but still not right:
fleur:/tmp# rmdir foo
fleur:/tmp# mkdir foo
fleur:/tmp# touch foo/blah
fleur:/tmp# mount -o bind foo foo
fleur:/tmp# mount -o remount,ro foo
fleur:/tmp# touch foo/blah
touch: cannot touch `foo/blah': Read-only file system
fleur:/tmp# umount foo
fleur:/tmp# touch foo/blah
fleur:/tmp# 

So it works, just not quite as you'd expect :/

Cheers,
-- 
Brett Parker


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-08 Thread Peter Palfrader
On Fri, 08 May 2009, Peter Palfrader wrote:

> wea...@intrepid:~/tmp$ mkdir foo
> wea...@intrepid:~/tmp$ touch foo/bar
> wea...@intrepid:~/tmp$ sudo mount -o bind,ro foo foo
> wea...@intrepid:~/tmp$ touch foo/baz
> wea...@intrepid:~/tmp$ 
> 
> bind mounts don't do ro.

I have been told, that starting with 2.6.26 they do.  But only *iff* the
ro is done with a remount after the initial bind mounting.  How very not
useful.

-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-08 Thread Peter Palfrader
On Fri, 08 May 2009, David Weinehall wrote:

> On Thu, May 07, 2009 at 07:27:08PM -0500, Manoj Srivastava wrote:
> > No. But we do leave /usr read-only the rest of the time, which
> >  is often 99.999% of the time. A separate /usr is required for this.
> 
> Uhm, no?
> 
> mount --bind /usr /usr
> 
> Should do the trick (the same mount -o remount,rw / remount,ro then
> applies).  all thanks to the magic of subtrees :)

Yeah.  Right.

wea...@intrepid:~/tmp$ mkdir foo
wea...@intrepid:~/tmp$ touch foo/bar
wea...@intrepid:~/tmp$ sudo mount -o bind,ro foo foo
wea...@intrepid:~/tmp$ touch foo/baz
wea...@intrepid:~/tmp$ 

bind mounts don't do ro.
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-08 Thread David Weinehall
On Thu, May 07, 2009 at 07:27:08PM -0500, Manoj Srivastava wrote:
> On Thu, May 07 2009, Ben Finney wrote:
> 
> > Manoj Srivastava  writes:
> >
> >> On Thu, May 07 2009, Josselin Mouette wrote:
> >> 
> >> > Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
> >> >> Those who want a read-only ‘/usr’ don't seriously try to leave it
> >> >> read-only while installing or upgrading packages, do they?
> >> 
> >> ,[ Excerpt from /etc/apt/apt.conf ]
> >> | DPkg 
> >> | {
> >> |// Auto re-mounting of a readonly /usr
> >> |Pre-Invoke  {"mount -o remount,rw /usr";};
> >> |Post-Invoke {"mount -o remount,ro /usr";};
> >> | };
> >> `
> >
> > Exactly. So this is *not* “leave /usr read-only while installing or
> > upgrading packages”. Thanks for providing another case in point.
> 
> No. But we do leave /usr read-only the rest of the time, which
>  is often 99.999% of the time. A separate /usr is required for this.

Uhm, no?

mount --bind /usr /usr

Should do the trick (the same mount -o remount,rw / remount,ro then
applies).  all thanks to the magic of subtrees :)


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-07 Thread Giacomo Catenazzi
Ben Finney wrote:
> Manoj Srivastava  writes:
> 
>> On Thu, May 07 2009, Josselin Mouette wrote:
>>
>>> Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
 Those who want a read-only ‘/usr’ don't seriously try to leave it
 read-only while installing or upgrading packages, do they?
>> ,[ Excerpt from /etc/apt/apt.conf ]
>> | DPkg 
>> | {
>> |// Auto re-mounting of a readonly /usr
>> |Pre-Invoke  {"mount -o remount,rw /usr";};
>> |Post-Invoke {"mount -o remount,ro /usr";};
>> | };
>> `
> 
> Exactly. So this is *not* “leave /usr read-only while installing or
> upgrading packages”. Thanks for providing another case in point.
> 

Sometime I wonder on which kind of list I'm subscribed.

ciao
cate


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-07 Thread Manoj Srivastava
On Thu, May 07 2009, Ben Finney wrote:

> Manoj Srivastava  writes:
>
>> On Thu, May 07 2009, Josselin Mouette wrote:
>> 
>> > Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
>> >> Those who want a read-only ‘/usr’ don't seriously try to leave it
>> >> read-only while installing or upgrading packages, do they?
>> 
>> ,[ Excerpt from /etc/apt/apt.conf ]
>> | DPkg 
>> | {
>> |// Auto re-mounting of a readonly /usr
>> |Pre-Invoke  {"mount -o remount,rw /usr";};
>> |Post-Invoke {"mount -o remount,ro /usr";};
>> | };
>> `
>
> Exactly. So this is *not* “leave /usr read-only while installing or
> upgrading packages”. Thanks for providing another case in point.

No. But we do leave /usr read-only the rest of the time, which
 is often 99.999% of the time. A separate /usr is required for this.

manoj

-- 
"A complex system that works is invariably found to have evolved from a
simple system that worked." -- John Gall, _Systemantics_
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-07 Thread Ben Finney
Manoj Srivastava  writes:

> On Thu, May 07 2009, Josselin Mouette wrote:
> 
> > Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
> >> Those who want a read-only ‘/usr’ don't seriously try to leave it
> >> read-only while installing or upgrading packages, do they?
> 
> ,[ Excerpt from /etc/apt/apt.conf ]
> | DPkg 
> | {
> |// Auto re-mounting of a readonly /usr
> |Pre-Invoke  {"mount -o remount,rw /usr";};
> |Post-Invoke {"mount -o remount,ro /usr";};
> | };
> `

Exactly. So this is *not* “leave /usr read-only while installing or
upgrading packages”. Thanks for providing another case in point.

-- 
 \  “Some forms of reality are so horrible we refuse to face them, |
  `\ unless we are trapped into it by comedy. To label any subject |
_o__)unsuitable for comedy is to admit defeat.” —Peter Sellers |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-07 Thread Manoj Srivastava
On Thu, May 07 2009, Josselin Mouette wrote:

> Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
>> Those who want a read-only ‘/usr’ don't seriously try to leave it
>> read-only while installing or upgrading packages, do they?

,[ Excerpt from /etc/apt/apt.conf ]
| DPkg 
| {
|// Auto re-mounting of a readonly /usr
|Pre-Invoke  {"mount -o remount,rw /usr";};
|Post-Invoke {"mount -o remount,ro /usr";};
| };
`

manoj
-- 
The rule on staying alive as a program manager is to give 'em a number
or give 'em a date, but never give 'em both at once.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-07 Thread Richard A Nelson

On Tue, 5 May 2009, Russ Allbery wrote:


Stefano Zacchiroli  writes:


Yes, the most repeated argument has been mount /usr via NFS.
Unfortunately, nobody yet explained how do they update the resulting
cluster of machines.


It's not particularly difficult.  You update the system master and push
that update into NFS, synchronizing any non-/usr data as you need to
across all the systems mounting that NFS partition.  If you don't want
to take downtime, you have two chroots on the NFS server and pivot
systems back and forth between the two chroots as you do updates.


I have parts of /usr and /var shared via NFS and use cfengine to
push/pull related updates to /etc and other non-shared locations.

cfengine will keep the non-shared portions synchronized, and restart
services when their config files are updated.


People did and still do this all the time with AFS.  It's pretty
well-established how to make it work.


'Tis a little harder now with my servers  being split betwixt i686 and 
amd64 machines (db format differs, so I had to use inn peering, not 
shared spool, etc).



I personally don't care any more because hard drives have gotten a lot
bigger, but it's technically quite feasible.


Yes, but I see this as an management of space/time/etc trade-off.

For me the big items for standalone /usr are mentioned elsewhere -
I tend to have a separate /boot and put everthing else in a (encrypted
for laptops) LVM where resizing/moving/backup/security/etc all argure
for independant partitions.


I see as quite pointless to use "let's export /usr via NFS" as an
argument, if Debian does not provide a way to make that setup tenable.


Certainly looks tenable right now to me.


Indeed, tenable - and working
--
Rick Nelson
 `You have been unsubscribed from the high energy personal
 protection devices mailing list'
 I dont remember getting into the mailing list


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-07 Thread Henrique de Moraes Holschuh
On Thu, 07 May 2009, Ben Finney wrote:
> Those who want a read-only ???/usr??? don't seriously try to leave it
> read-only while installing or upgrading packages, do they?

No.  And we hook apt to automatically remount stuff rw before it, and try to
remount ro after.  It is easy, it works *perfectly*, and it has done so for
longer than I care to remember.

When the ro remount fails, you know you have some checkrestart work to do to
get all updates in core, so it has helped our security upgrade team as well,
even if their "procedure sheet" already tells them to check for old
processes and libraries anyway.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-07 Thread Josselin Mouette
Le jeudi 07 mai 2009 à 09:37 +0200, Giacomo A. Catenazzi a écrit :
> Stephen Gran wrote:
> >> But with RPM this works!
> > If that is the case, that's about the only thing that works with RPM.
> Or I missed what RPM do with read-only partitions?

Next time I’ll add the  tags.

There has been a discussion some time ago about RPM updating the
database and marking the package as upgraded while nothing had changed
on the filesystem because it is mounted read-only. I don’t know whether
this has been fixed in RPM since then.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée


Re: deprecating /usr as a standalone filesystem?

2009-05-07 Thread Giacomo A. Catenazzi

Stephen Gran wrote:

This one time, at band camp, Josselin Mouette said:

Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :

Those who want a read-only ‘/usr’ don't seriously try to leave it
read-only while installing or upgrading packages, do they?

But with RPM this works!


If that is the case, that's about the only thing that works with RPM.


*works* ? I don't think this is a "feature".
IMHO the right thing is like debian: admins explicitly
add hook to remount partition rw, before installing package.
I don't like that by "default" a package management will override
mount options.

Or I missed what RPM do with read-only partitions?

ciao
cate

PS: moving to d-curiosa?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-07 Thread Stephen Gran
This one time, at band camp, Josselin Mouette said:
> Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
> > Those who want a read-only ‘/usr’ don't seriously try to leave it
> > read-only while installing or upgrading packages, do they?
> 
> But with RPM this works!

If that is the case, that's about the only thing that works with RPM.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature


Re: deprecating /usr as a standalone filesystem?

2009-05-07 Thread Josselin Mouette
Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
> Those who want a read-only ‘/usr’ don't seriously try to leave it
> read-only while installing or upgrading packages, do they?

But with RPM this works!

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée


Re: deprecating /usr as a standalone filesystem?

2009-05-07 Thread Joerg Jaspert

>> So, does anybody still see reasons to continue supporting a standalone
>> /usr?
> There had been lots of responses to that.

> You havent presented any supporting your request, so why do you
> want it? Please provide a detailed real-world case. A partial list of
> invalid reasons is: - "Some upstream wont fix his software to be FHS
> compatible"

As there is still not a single response from the original proposer as to
why this should be done, I think this is a dead issue. If not even the
proposer cares enough to present some real world use cases why one wants
to do it, why should Debian at a whole care?

-- 
bye, Joerg
 I'm kinky and perverse, but my illness is laziness


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Ben Finney
Peter Samuelson  writes:

> Also, this procedure would be much more reliable if we said, in
> Policy, that maintainer scripts are not allowed to fail if /usr is not
> writable. (mount -o ro, SELinux, chattr +i, NFS root_squash,
> whatever.)
> 
> Would you support that policy? I suspect ldconfig would have to be
> patched in some way.

I certainly wouldn't. The maintainer scripts need to be able to do
whatever they need to do in order to get the package set up on the
system. That certainly includes changing things in ‘/usr’, which
requires that filesystem to be writable during package management.

Those who want a read-only ‘/usr’ don't seriously try to leave it
read-only while installing or upgrading packages, do they?

-- 
 \   “The optimist thinks this is the best of all possible worlds. |
  `\   The pessimist fears it is true.” —J. Robert Oppenheimer |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Matthew Johnson
On Thu May 07 00:38, Stefano Zacchiroli wrote:
> > What about the (many) arguments made here about the *other* reasons to
> > have /usr a separate filesystem?
> 
> I've nothing against them, I was countering only this precise
> argument.  FWIW, I haven't seen that many, though the one about
> read-only /usr was appropriate.

More to the point, has anyone actually presented any real arguments why
_not_ to allow it? I've not actually seen anything other than the OP
saying "things might need changing to support it" and then refusing to
go into detail.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature


Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Stefano Zacchiroli
On Wed, May 06, 2009 at 09:36:56PM +0200, Iustin Pop wrote:
> > - We decide that if you want to mount /usr remotely you are on your
> >   own.
> > 
> >   If we do so, we should stop using "mount /usr remotely" as an
> >   argument for keeping /usr as a single filesystem.
> What about the (many) arguments made here about the *other* reasons to
> have /usr a separate filesystem?

I've nothing against them, I was countering only this precise
argument.  FWIW, I haven't seen that many, though the one about
read-only /usr was appropriate.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature


Re: deprecating /usr as a standalone filesystem? [386 support]

2009-05-06 Thread Josselin Mouette
Le mardi 05 mai 2009 à 23:38 +0200, Frank Lin PIAT a écrit :
> Interesting. I thought 386 wasn't supported anymore (?)

AFAIK the kernel is able to emulate a 486 when running on a 386.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée


Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Russ Allbery
Philipp Kern  writes:
> On 2009-05-06, Russ Allbery  wrote:

>> I think it's pretty unlikely that *most* Debian machines are done
>> that way.  There are a lot better tools for keeping large numbers of
>> systems in sync these days than simple cloning from golden images,
>> and a lot of drawbacks to the golden image approach.
>
> We do the same with ~12 clients.  One master image that's declared
> stable by rsyncing it using hardlinks[0] on the server and from there
> rsynced to the clients which reboot automatically if there are pending
> updates.  After the rsyncing it does local profile-based "patching".
>
> I wonder about the drawbacks of this because it works really nice for
> us.  (Of course there's the downtime problem, but that's no problem
> for us, as those are clients not servers.)

If you start getting node variation, it turns into a headache.  If
you're in a situation where you're assured of no node variation, it
works fairly well within that situation, but we want one solution that
works for *all* types of servers we run, whether clusters or one-offs or
smaller sets of load-balanced servers.

You can also get a slow accumulation of cruft in your golden image over
time, and if you don't keep good documentation, it's really easy to
discover that you no longer know exactly how to rebuild your golden
image if you need to (such as for a new OS release).

> But why bother to do a complete reinstall everytime something changed
> if you could just sync the delta.  (And yes, I'm roughly aware that
> there are something like softupdates in FAI too, but still.)

We don't do it every time something changes; usually we use Puppet to
push incremental changes.  We rebuild systems whenever we repurpose them
or whenever we do a major OS upgrade.

I like rebuilding systems from first principles for exactly the same
reason that I like recompiling the whole Debian archive.  It tests your
process.  Having a complete process for building a system rather than a
static system image that you may or may not be able to reproduce makes
it much easier to migrate to new releases of the OS (because you can
layer most of your policy on top of the new release), change any part of
the process, etc.

I've done this pretty much every different way you can with a lot of
versions of UNIX: golden images, portions of the file system in network
file systems, specific change application scripts, everything with
native packages, mixes of native packaging and configuration management
systems, etc.  For a fairly heterogeneous mix of servers that may
include some clusters of identical systems, I think FAI plus a good
configuration management system like Puppet is the way to go.  It makes
me feel the most comfortable about the upgrade path, the testing of the
whole system, and the robustness of the environment.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Iustin Pop
On Wed, May 06, 2009 at 02:56:20PM +0200, Stefano Zacchiroli wrote:
> In particular, from the replies to my question the picture I get is
> that everybody is using ad hoc solutions to implement what some people
> are pretending to be properly supported by Debian. I found it not
> defendable, maybe it's just me, maybe it's just bad marketing.
> 
> Of the two one:
> 
> - We decide that mounting /usr remotely is a Debian goal.
> 
>   If we do so, the mechanisms to make it work should not be as ad hoc
>   as this thread as hinted. We should provide a package explicitly
>   made to make this workflow tenable and point our users to it.
> 
> - We decide that if you want to mount /usr remotely you are on your
>   own.
> 
>   If we do so, we should stop using "mount /usr remotely" as an
>   argument for keeping /usr as a single filesystem.

What about the (many) arguments made here about the *other* reasons to
have /usr a separate filesystem?

regards,
iustin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Thibaut Paumard


Le 6 mai 09 à 00:30, Stefano Zacchiroli a écrit :


On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote:
So, does anybody still see reasons to continue supporting a  
standalone

/usr?

There had been lots of responses to that.


Yes, the most repeated argument has been mount /usr via NFS.
Unfortunately, nobody yet explained how do they update the resulting
cluster of machines.


I guess there is a way if you want to upgrade your machines one by  
one : temporarily have 3 instances of /usr. The not-yet-upgraded  
machines will use /usr(old), the upgraded machines /usr(new), and the  
machine currently being upgraded will work on a /usr(tmp) which is a  
copy of /usr(old) and which it will upgrade into a copy of /usr(new).


Now there is another way, which is to upgrade just one machine and  
clone its hard drive (except for the couple of files which need to be  
different).


So that's two fairly easy ways to do it. There may be more clever ones.

T.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Henrique de Moraes Holschuh
On Tue, 05 May 2009, Marco d'Itri wrote:
> I know that Debian supports this, but I also know that maintaning
> forever large changes to packages for no real gain sucks.

I wonder what these are, and I hope you will start a separate thread with
that information.

> So, does anybody still see reasons to continue supporting a standalone
> /usr?

Yes.  We use that mode in _ALL_ servers.  We keep it read-only except while
applying security updates.  This means it *never* gets hosed by crashes, and
it is less vulnerable to accidental damage.

/ is also protected, using different strategies: it has to be read-write if
you want to keep sane right now, so we have in / only /root, /boot, /etc,
/bin and /sbin, plus mountpoints.  These almost never change, so the
filesystem is rarely modified.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Josselin Mouette
Le mercredi 06 mai 2009 à 08:57 -0500, Peter Samuelson a écrit :
> Also, this procedure would be much more reliable if we said, in Policy,
> that maintainer scripts are not allowed to fail if /usr is not writable.
> (mount -o ro, SELinux, chattr +i, NFS root_squash, whatever.)
> 
> Would you support that policy?  I suspect ldconfig would have to be
> patched in some way.

So, after people pestered me so that I moved python-support files
from /var to /usr, now others will complain again and require them to go
again to /var?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée


Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Gabor Gombas
On Wed, May 06, 2009 at 03:31:23PM +0200, Stefano Zacchiroli wrote:

> Anyhow, *you* don't understand the problem and you are probably the
> only one thinking I'm selling vapor. From other people's replies I
> conclude that the problem is quite clear and my vapor was so concrete
> that others hinted at technical solutions.  But let me spell the
> problem out for you, as you are raising the tone of the discussion
> with exclamation marks (which was not my intention).
> 
> The problem is that our package manager (dpkg) assumes it is in charge
> of files which reside on different top-level FHS directories: /usr,
> /var, /boot, /bin, /sbin, /lib, /lib64, ...
> 
> In a scenario where /usr is remotely exported for NFS mounting, if you
> use dpkg on the exporting machine, client machines will get out of
> sync. Some files need to be copied over statically and, more
> interestingly, maintainer scripts will need to be re-run on client
> machines to deliver their side effects to all machines. Also the
> status of the dpkg database need to be synced with clients.
> 
> 
> My argument is mainly that we should not ask our user to do the above
> sync by hand, still claiming we "support" it.

But _NOBODY_ said to support the sync part in Debian. Just leave things
as-is, i.e. let it possible to have /usr as a separate filesystem. We
can do the rest, thank you very much. The fact that clients can get out
of sync is perfectly understood and handled when needed. There is
nothing new here; mounting /usr over NFS on Solaris boxes a decade ago
had exactly the same basic issues.

Don't ask users to do the sync by hand. Just _let_ them do it if they
wish.

Mounting /usr over NFS is an old technique. I wouldn't recommend it
to anyone today but it exists and deliberately breaking it just because
you do not like it is stupid.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Giacomo A. Catenazzi

Stefano Zacchiroli wrote:

On Wed, May 06, 2009 at 03:06:34PM +0200, Giacomo A. Catenazzi wrote:

But system administration is per definition ad hoc solution.
This is our power. Why we give sources? Also to allow us
to tweak debian.


This is a utterly poor argument.
I can easily twist it against you by saying "why we give binaries"?
We can just offer sources, system administrators will be able to
compile them.


I said *also*. 10 years ago this was a real argument:
"use Linux because you can adapt to your local needs".
I never installed a Debian system, which is 100% Debian.
It always have some of my personality.

For this case I mean: I don't think we should support
directly, but we should allow our sysadmin to tweak
/usr




Was this a topic of last meeting of the Italian cabal?


Is there anything useful in raising the "Italian cabal" here? The fact
I'm Italian has nothing to do with my arguments, pretty much as your
nationality has nothing to do with yours.
Or else add smileys if it was meant to be a joke.


sorry! Yes, it was meant as a joke.



But you are still selling us vapor!
We still don't understand the problem!


Anyhow, *you* don't understand the problem and you are probably the
only one thinking I'm selling vapor. From other people's replies I
conclude that the problem is quite clear and my vapor was so concrete
that others hinted at technical solutions.  But let me spell the
problem out for you, as you are raising the tone of the discussion
with exclamation marks (which was not my intention).

The problem is that our package manager (dpkg) assumes it is in charge
of files which reside on different top-level FHS directories: /usr,
/var, /boot, /bin, /sbin, /lib, /lib64, ...

In a scenario where /usr is remotely exported for NFS mounting, if you
use dpkg on the exporting machine, client machines will get out of
sync. Some files need to be copied over statically and, more
interestingly, maintainer scripts will need to be re-run on client
machines to deliver their side effects to all machines. Also the
status of the dpkg database need to be synced with clients.


No. So I think also you did not understand the real problem.
The /usr in NFS is one interpretation, but I really think it was not
the original problem. Such ad hoc methods was never supported.

[BTW we saw in the thread that we could share also / on multiple systems!]

I think the problem is having /usr in an other partition
(a larger set of configuration, and in this case, we supported it), thus
having problem at boot, on what the init script could expect
(program and libraries).

Sorry for my tone, but we are disturbed on the fact that
a proposal was done without giving reasons.

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Peter Samuelson

[Stefano Zacchiroli]
>   The trick of fiddling the dpkg database on the client machine and
>   then run "dpkg --configure -a" there is indeed nice. But again,
>   requesting our users to do that, potentially messing up with the
>   dpkg database, is IMO not something we can call being properly
>   supported in Debian. If it is supposed to work that way, we have to
>   provide higher level tools that do that for our users.

Also, this procedure would be much more reliable if we said, in Policy,
that maintainer scripts are not allowed to fail if /usr is not writable.
(mount -o ro, SELinux, chattr +i, NFS root_squash, whatever.)

Would you support that policy?  I suspect ldconfig would have to be
patched in some way.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Giacomo A. Catenazzi

Stefano Zacchiroli wrote:

A few side notes:

* everybody overlooked the subtle theoretical problem that our
  maintainer scripts can potentially do *everything* on the file
  system and *everywhere*, and that they are written in a Turing
  complete language (shell script). This means that you cannot, in the
  general case discover what they have touched. As a consequence you
  can not simply rely on the dpkg database to know what you have to
  propagate.


But package installation is nullpotent. You can install again
on every system. You still have one /usr, but right data in other
places.

Is it so important a consistent database? Things will still work.
Remember that our policy require not to hardcore paths, so that
a sysadmin can overwrite program using /usr/local.

This means indirectly that what it is in database and what
it is installed doesn't need to be consistent with
what it is really used.

And I don't understand why the dpkg database MUST be accurate.
dpkg is smart enough to do the right things anyways.



  The trick of fiddling the dpkg database on the client machine and
  then run "dpkg --configure -a" there is indeed nice. But again,
  requesting our users to do that, potentially messing up with the
  dpkg database, is IMO not something we can call being properly
  supported in Debian. If it is supposed to work that way, we have to
  provide higher level tools that do that for our users.


I agree that we must not support (helping users) such systems (but
usually they have good sysadmins), but I find stupid to make life harder
to such sysadmins.

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Stefano Zacchiroli
On Wed, May 06, 2009 at 03:06:34PM +0200, Giacomo A. Catenazzi wrote:
> But system administration is per definition ad hoc solution.
> This is our power. Why we give sources? Also to allow us
> to tweak debian.

This is a utterly poor argument.
I can easily twist it against you by saying "why we give binaries"?
We can just offer sources, system administrators will be able to
compile them.

A distribution is about integration of unrelated softwares and is
about making easier / more manageable tasks for various kind of users,
including system administrators.

> Debian is a distribution, not a complete solution.
> I think we have a different idea of what is debian.

Maybe we have.

> Was this a topic of last meeting of the Italian cabal?

Is there anything useful in raising the "Italian cabal" here? The fact
I'm Italian has nothing to do with my arguments, pretty much as your
nationality has nothing to do with yours.
Or else add smileys if it was meant to be a joke.

> But you are still selling us vapor!
> We still don't understand the problem!

Anyhow, *you* don't understand the problem and you are probably the
only one thinking I'm selling vapor. From other people's replies I
conclude that the problem is quite clear and my vapor was so concrete
that others hinted at technical solutions.  But let me spell the
problem out for you, as you are raising the tone of the discussion
with exclamation marks (which was not my intention).

The problem is that our package manager (dpkg) assumes it is in charge
of files which reside on different top-level FHS directories: /usr,
/var, /boot, /bin, /sbin, /lib, /lib64, ...

In a scenario where /usr is remotely exported for NFS mounting, if you
use dpkg on the exporting machine, client machines will get out of
sync. Some files need to be copied over statically and, more
interestingly, maintainer scripts will need to be re-run on client
machines to deliver their side effects to all machines. Also the
status of the dpkg database need to be synced with clients.


My argument is mainly that we should not ask our user to do the above
sync by hand, still claiming we "support" it.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature


Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Peter Palfrader
On Wed, 06 May 2009, Stefano Zacchiroli wrote:

> Of the two one:
> 
> - We decide that mounting /usr remotely is a Debian goal.
> 
>   If we do so, the mechanisms to make it work should not be as ad hoc
>   as this thread as hinted. We should provide a package explicitly
>   made to make this workflow tenable and point our users to it.

If we were limited by what debian (and d-i) can do out of the box this
would be a sad world.  And it'd make most software and Debian pretty
useless in a lot of cases.

It's kind of the job of a sysadmin to take what Debian (or any other
vendor) gives them and integrate this into an environment that fulfill's
the local requirements.

The level of support that Debian provides for mounting remote /usr
filesystems is apparently just fine or at least sufficient for the kind
of user that makes use of it.

Just don't break crap that has worked for years for no other reason than
"I want to".

-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Giacomo A. Catenazzi

Stefano Zacchiroli wrote:

On Wed, May 06, 2009 at 09:38:39AM -0300, Daniel Ruoso wrote:

Simple.



Sure, that's precisely what I'd call being properly supported in
Debian.


In particular, from the replies to my question the picture I get is
that everybody is using ad hoc solutions to implement what some people
are pretending to be properly supported by Debian. I found it not
defendable, maybe it's just me, maybe it's just bad marketing.


But system administration is per definition ad hoc solution.
This is our power. Why we give sources? Also to allow us
to tweak debian.

Debian is a distribution, not a complete solution.
I think we have a different idea of what is debian.



Of the two one:

- We decide that mounting /usr remotely is a Debian goal.

  If we do so, the mechanisms to make it work should not be as ad hoc
  as this thread as hinted. We should provide a package explicitly
  made to make this workflow tenable and point our users to it.

- We decide that if you want to mount /usr remotely you are on your
  own.

  If we do so, we should stop using "mount /usr remotely" as an
  argument for keeping /usr as a single filesystem.


But you are still selling us vapor!
We still don't understand the problem!
Was this a topic of last meeting of the Italian cabal?

What is the problem:
- remote /usr not supported?
- /usr in a different partition ?
- union mount could solve this?

we cannot discuss without knowing the real problem!

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Stefano Zacchiroli
On Wed, May 06, 2009 at 09:38:39AM -0300, Daniel Ruoso wrote:
> Simple.


Sure, that's precisely what I'd call being properly supported in
Debian.


In particular, from the replies to my question the picture I get is
that everybody is using ad hoc solutions to implement what some people
are pretending to be properly supported by Debian. I found it not
defendable, maybe it's just me, maybe it's just bad marketing.

Of the two one:

- We decide that mounting /usr remotely is a Debian goal.

  If we do so, the mechanisms to make it work should not be as ad hoc
  as this thread as hinted. We should provide a package explicitly
  made to make this workflow tenable and point our users to it.

- We decide that if you want to mount /usr remotely you are on your
  own.

  If we do so, we should stop using "mount /usr remotely" as an
  argument for keeping /usr as a single filesystem.


A few side notes:

* various people replying to my request mentioned that in such a
  setup, you are not expected to upgrade "too often" the machine
  exporting /usr

* everybody overlooked the subtle theoretical problem that our
  maintainer scripts can potentially do *everything* on the file
  system and *everywhere*, and that they are written in a Turing
  complete language (shell script). This means that you cannot, in the
  general case discover what they have touched. As a consequence you
  can not simply rely on the dpkg database to know what you have to
  propagate.

  The trick of fiddling the dpkg database on the client machine and
  then run "dpkg --configure -a" there is indeed nice. But again,
  requesting our users to do that, potentially messing up with the
  dpkg database, is IMO not something we can call being properly
  supported in Debian. If it is supposed to work that way, we have to
  provide higher level tools that do that for our users.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature


Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Marco d'Itri
On May 05, Steve Langasek  wrote:

> This is false for Ubuntu.  Not only is it supported, but significant effort
> was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as
> pertains to wpasupplicant.
You may want to discuss this with Keybuk then, because he still
disagrees.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Daniel Ruoso
Em Qua, 2009-05-06 às 00:30 +0200, Stefano Zacchiroli escreveu:
> On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote:
> > > So, does anybody still see reasons to continue supporting a standalone
> > > /usr?
> > There had been lots of responses to that.
> Yes, the most repeated argument has been mount /usr via NFS.
> Unfortunately, nobody yet explained how do they update the resulting
> cluster of machines.

Simple.

You have a single /usr shared-mounted for several instances and a a /
for each machine. Then you run the upgrade in one of those images and do
the following:

 1 - use a script to extract files not in /usr in that packages and
install it in each root mount
 2 - use a script to change the dpkg database in each root mount telling
that the packages were unpacked but not configured.
 3 - run dpkg --configure -a in each root mount to get the maint scripts
to be run...
 4 - profit

daniel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Philipp Kern
On 2009-05-06, Russ Allbery  wrote:
> Giacomo Catenazzi  writes:
>> - On large parallel systems, people use something more than a base debian
>>   console installation.
>>   Usually on net you have a complete copy for root, var etc
>>   (in case of compromised computers. Very handy instead of reinstalling the
>>   system)
>>   So it is easier also to have a rsync script (without some dirs)
>>   And on infrequent security update where data format change,
>>   let sysadmin implement a tool to update such numberous systems.
>>   But such case is seldom.
>>   I really think that *most* debian machines are done in this way
>>   (because such systemns have huge number of debian machine, and
>>   debian is a very good distribution for such setups)
> I think it's pretty unlikely that *most* Debian machines are done that
> way.  There are a lot better tools for keeping large numbers of systems
> in sync these days than simple cloning from golden images, and a lot of
> drawbacks to the golden image approach.

We do the same with ~12 clients.  One master image that's declared
stable by rsyncing it using hardlinks[0] on the server and from there
rsynced to the clients which reboot automatically if there are pending
updates.  After the rsyncing it does local profile-based "patching".

I wonder about the drawbacks of this because it works really nice for
us.  (Of course there's the downtime problem, but that's no problem
for us, as those are clients not servers.)

Sadly rsync still does too much I/O on the servers in our setup, but
if that gets a problem we'll probably go with aufs and have an image on
the client which remainds static there.

> Also, reinstalling systems is completely trivial if you have a decent
> FAI infrastructure.  It takes us about ten minutes to rebuild a server
> and reinstall all application software, and that's mostly waiting for
> the system BIOS boot-up checks and the small amount of manual keying
> we've not bothered to automate yet.

But why bother to do a complete reinstall everytime something changed
if you could just sync the delta.  (And yes, I'm roughly aware that
there are something like softupdates in FAI too, but still.)

Kind regards,
Philipp Kern

[0] Actually there's one test image and the stable images are hardlinked
within themselves, so that changes in the test image do not propagate
to the stable images.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Josselin Mouette
Le mardi 05 mai 2009 à 23:15 -0700, Russ Allbery a écrit :
> I think it's pretty unlikely that *most* Debian machines are done that
> way.  There are a lot better tools for keeping large numbers of systems
> in sync these days than simple cloning from golden images, and a lot of
> drawbacks to the golden image approach.

You’d be surprised to see the number of HPC people who are wasting their
time with golden images. And the even larger number of HPC people who
don’t even have an automated node deployment mechanism.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée


Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Josselin Mouette
Le mardi 05 mai 2009 à 16:25 -0700, Russ Allbery a écrit :
> It's not particularly difficult.  You update the system master and push
> that update into NFS, synchronizing any non-/usr data as you need to
> across all the systems mounting that NFS partition.

Sure, but what is the point of doing that instead of exporting / over
NFS ? Remember, we support read-only root partition setups now.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée


Re: deprecating /usr as a standalone filesystem?

2009-05-06 Thread Gabor Gombas
On Wed, May 06, 2009 at 12:30:14AM +0200, Stefano Zacchiroli wrote:

> Of course the problem is that if you update on the NFS server, then
> related /etc and /var files [1] will not get updated on the NFS client
> machines and you need to propagate changes there.

One thing to remember is when you export /usr (or "/") over NFS, then
you usually do not expect to install new software often (maybe once or
twice a year), and security updates rarely bring big changes under /etc
or /var.

/etc can be managed with a couple of scripts; if you have a non-trivial
amount of machines you already have the scripts to populate and
customize it for a new machine. After an update, you just re-run that
script for all the clients and you're done.

/var is not an issue either. You can mount it read-only just like /usr
and then you can mount some tmpfs instances over the locations where
write access is really needed. /etc/fstab fragment:

tmpfs   /tmptmpfs   size=100m,mode=1777 0   0
/tmp/var/tmpbindbind0   0
tmpfs   /var/logtmpfs   size=10m0   0
tmpfs   /var/lib/gdmtmpfs   size=10m0   0
tmpfs   /var/lib/xkbtmpfs   size=10m0   0
tmpfs   /var/lib/nfstmpfs   size=10m0   0
tmpfs   /var/cache/hald tmpfs   size=10m0   0
tmpfs   /media  tmpfs   size=128k   0   0

You of course need a couple of mkdir/chown commands in an init script to
create some required subdirectories.

If you need persistence, then you mount a writable FS somewhere else,
and you do something like

mount --bind /home/terem/boinc-client/$HOSTNAME /var/lib/boinc-client

(that's from a running cluster setup).

If I take a look of what is actually under /var on that cluster, then I
get:

nfs-server# du -s .
147300  .
nfs-server# du -s cache lib/apt lib/aptitude lib/dpkg log
[...]
135616  total

So even if you want a local /var on every machine, you can ignore over
92% of the data when you synchronize with say rsync (you can actually
ignore even more, but then the above "du -s" line would have been too
long).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem? [/usr on NFS]

2009-05-05 Thread Russ Allbery
Frank Lin PIAT  writes:
> On Tue, 2009-05-05 at 16:25 -0700, Russ Allbery wrote:

>> It's not particularly difficult.  You update the system master and
>> push that update into NFS, synchronizing any non-/usr data as you
>> need to across all the systems mounting that NFS partition.

> I have always been skeptical about sharing /usr on Debian, especially
> I've always wondered is how you upgrade the remote (nfs-mounted)
> systems?
> * How to upgrade /bin, /lib... files?
> * Can dpkg be told to not touch /usr on those machines?
> * Some (pre|post)(inst|rm) scripts use files in /usr... Aren't they
>   guaranteed to behave in unpredictable way, if the version is /usr
>   aren't the one expected by those scripts?

I think it would be fairly difficult without using a golden image
approach, where there's one system (or chroot on an NFS server) that you
upgrade and then push the non-/usr results to all the systems mounting
/usr.  Doing that is fairly straightforward, though.

Don't get me wrong: I don't do this, nor do I have any plans to do
this.  Disk is too cheap to bother and there are better ways of keeping
systems in sync these days, IMO.  But it's a very long-standing sysadmin
technique, I wouldn't be surprised if some people still use it, and it's
certainly technically doable.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem? [/usr on NFS]

2009-05-05 Thread Frank Lin PIAT
On Tue, 2009-05-05 at 16:25 -0700, Russ Allbery wrote:
> Stefano Zacchiroli  writes:
> 
> > Yes, the most repeated argument has been mount /usr via NFS.
> > Unfortunately, nobody yet explained how do they update the resulting
> > cluster of machines.
> 
> It's not particularly difficult.  You update the system master and push
> that update into NFS, synchronizing any non-/usr data as you need to
> across all the systems mounting that NFS partition.

I have always been skeptical about sharing /usr on Debian, especially
I've always wondered is how you upgrade the remote (nfs-mounted)
systems?
* How to upgrade /bin, /lib... files?
* Can dpkg be told to not touch /usr on those machines?
* Some (pre|post)(inst|rm) scripts use files in /usr... Aren't they
  guaranteed to behave in unpredictable way, if the version is /usr
  aren't the one expected by those scripts?

I used lessdisk[1] in sarge, but it used to export the whole tree over
NFS.

Regards,

Franklin

P.S. I like the idea to use encrypted partition for the whole system,
 excepts /usr.

[1] http://archive.debian.net/sarge/lessdisks


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Johan Henriksson

> Well, some people argued for that.  Like you, I'm wondering how one
> actually does this in practice!  However there are some rather more
> reasonable uses which have been mentioned:
>
> - read-only /usr (for security)
> - backups
> - recovery (ability to mount root only; important if there's fs corruption)
> - on-line resizing
> - using LVM and/or RAID
>   (Note: With modern Debian initramfs it is quite possible to have
>/ on LVM [on RAID] since so long as /boot lives outside the
>initramfs can bring up RAID and initialise LVM to mount the
>rootfs.  The system I'm physically typing this on has such a
>setup.)
>   
I keep a /usr because I suspect it gives more performance. unlike the rest of 
the disk, one doesn't read and write it all the time, so fragmentation should 
be less if it is kept separate. one can also use a filesystem type more 
suitable for this behaviour (reiserfs is probably not optimal)

/Johan

-- 
--

Johan Henriksson
MSc Engineering
PhD student, Karolinska Institutet
http://mahogny.areta.org http://www.endrov.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Russ Allbery
Giacomo Catenazzi  writes:

> - On large parallel systems, people use something more than a base debian
>   console installation.
>   Usually on net you have a complete copy for root, var etc
>   (in case of compromised computers. Very handy instead of reinstalling the
>   system)
>   So it is easier also to have a rsync script (without some dirs)
>   And on infrequent security update where data format change,
>   let sysadmin implement a tool to update such numberous systems.
>   But such case is seldom.
>   I really think that *most* debian machines are done in this way
>   (because such systemns have huge number of debian machine, and
>   debian is a very good distribution for such setups)

I think it's pretty unlikely that *most* Debian machines are done that
way.  There are a lot better tools for keeping large numbers of systems
in sync these days than simple cloning from golden images, and a lot of
drawbacks to the golden image approach.

Also, reinstalling systems is completely trivial if you have a decent
FAI infrastructure.  It takes us about ten minutes to rebuild a server
and reinstall all application software, and that's mostly waiting for
the system BIOS boot-up checks and the small amount of manual keying
we've not bothered to automate yet.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Giacomo Catenazzi
Stefano Zacchiroli wrote:
> On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote:
>>> So, does anybody still see reasons to continue supporting a standalone
>>> /usr?
>> There had been lots of responses to that.
> 
> Yes, the most repeated argument has been mount /usr via NFS.
> Unfortunately, nobody yet explained how do they update the resulting
> cluster of machines.
> 
> Of course the problem is that if you update on the NFS server, then
> related /etc and /var files [1] will not get updated on the NFS client
> machines and you need to propagate changes there. I see as quite
> pointless to use "let's export /usr via NFS" as an argument, if Debian
> does not provide a way to make that setup tenable.

8-/
I really don't see the problems, and BTW debian provide also some tools.

- On large parallel systems, people use something more than a base debian
  console installation.
  Usually on net you have a complete copy for root, var etc
  (in case of compromised computers. Very handy instead of reinstalling the
  system)
  So it is easier also to have a rsync script (without some dirs)
  And on infrequent security update where data format change,
  let sysadmin implement a tool to update such numberous systems.
  But such case is seldom.
  I really think that *most* debian machines are done in this way
  (because such systemns have huge number of debian machine, and
  debian is a very good distribution for such setups)

- on homemade systems, Debian provide tools like apt-cron and
  other automatic update tools, which solve all problems
  (if one use only one distribution [like stable]).
  Also in this case, heuristic tell me that when we requires
  removing of a package, it is because it is substituted by
  an other, so no problems (when all systems are updated
  nearly at the same nightly time).
  It seems not a usual case that sysadmins remove packages
  from a single machine.

ciao
cate


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Russ Allbery
Stefano Zacchiroli  writes:

> Yes, the most repeated argument has been mount /usr via NFS.
> Unfortunately, nobody yet explained how do they update the resulting
> cluster of machines.

It's not particularly difficult.  You update the system master and push
that update into NFS, synchronizing any non-/usr data as you need to
across all the systems mounting that NFS partition.  If you don't want
to take downtime, you have two chroots on the NFS server and pivot
systems back and forth between the two chroots as you do updates.

People did and still do this all the time with AFS.  It's pretty
well-established how to make it work.

I personally don't care any more because hard drives have gotten a lot
bigger, but it's technically quite feasible.

> I see as quite pointless to use "let's export /usr via NFS" as an
> argument, if Debian does not provide a way to make that setup tenable.

Certainly looks tenable right now to me.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Roger Leigh
On Wed, May 06, 2009 at 12:30:14AM +0200, Stefano Zacchiroli wrote:
> On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote:
> > > So, does anybody still see reasons to continue supporting a standalone
> > > /usr?
> > There had been lots of responses to that.
> 
> Yes, the most repeated argument has been mount /usr via NFS.

Well, some people argued for that.  Like you, I'm wondering how one
actually does this in practice!  However there are some rather more
reasonable uses which have been mentioned:

- read-only /usr (for security)
- backups
- recovery (ability to mount root only; important if there's fs corruption)
- on-line resizing
- using LVM and/or RAID
  (Note: With modern Debian initramfs it is quite possible to have
   / on LVM [on RAID] since so long as /boot lives outside the
   initramfs can bring up RAID and initialise LVM to mount the
   rootfs.  The system I'm physically typing this on has such a
   setup.)

/dev/mapper/ravenclaw-root on / type ext3 (rw,relatime,errors=remount-ro)
/dev/sda2 on /boot type ext2 (rw,nodev)
/dev/mapper/ravenclaw-home on /home type ext3 
(rw,nosuid,nodev,usrquota,grpquota,user_xattr)
/dev/mapper/ravenclaw-usr on /usr type ext3 (rw,nodev,relatime)
/dev/mapper/ravenclaw-var on /var type ext3 (rw,nodev,user_xattr)
tmpfs on /tmp type tmpfs (rw,size=6G,mode=1777)
/dev/mapper/ravenclaw-chroots on /srv/chroot type ext3 (rw)
/dev/mapper/ravenclaw-mybook--backup on /srv/data/phd type ext4 
(rw,nosuid,nodev,user_xattr)
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)

I certainly think that there's continued need for a separable /usr at 
the present.  I'm intrigued as to what Marco's upstream is actually
doing!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Stefano Zacchiroli
On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote:
> > So, does anybody still see reasons to continue supporting a standalone
> > /usr?
> There had been lots of responses to that.

Yes, the most repeated argument has been mount /usr via NFS.
Unfortunately, nobody yet explained how do they update the resulting
cluster of machines.

Of course the problem is that if you update on the NFS server, then
related /etc and /var files [1] will not get updated on the NFS client
machines and you need to propagate changes there. I see as quite
pointless to use "let's export /usr via NFS" as an argument, if Debian
does not provide a way to make that setup tenable.

ACK on your second clarification request, though.

Cheers.

[1] Or anything else actually, given that maintainer scripts can
affect basically all the filesystem.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature


Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Joerg Jaspert
On 11741 March 1977, Marco d'Itri wrote:

> So, does anybody still see reasons to continue supporting a standalone
> /usr?

There had been lots of responses to that.

You havent presented any supporting your request, so why do you
want it? Please provide a detailed real-world case. A partial list of
invalid reasons is: - "Some upstream wont fix his software to be FHS
compatible"

-- 
bye, Joerg
Five exclamation marks, the sure sign of an insane mind.
-- Terry Pratchett, Reaper Man


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem? [386 support]

2009-05-05 Thread Frank Lin PIAT
On Tue, 2009-05-05 at 17:41 +0200, Bastien ROUCARIES wrote:
> On Tue, May 5, 2009 at 5:36 PM, Marco d'Itri  wrote:
> > I have been told by upstream maintainers of one of my packages and by
> > prominent developers of other distributions that supporting a standalone
> > /usr is too much work and no other distribution worth mentioning does it
> > (not Ubuntu, not Fedora, not SuSE).
> >
> > I know that Debian supports this, but I also know that maintaning
> > forever large changes to packages for no real gain sucks.
> >
> > So, does anybody still see reasons to continue supporting a standalone
> > /usr?
> > If you do, please provide a detailed real-world use case.
> > A partial list of invalid reasons is:
> > - "I heard that this was popular in 1998"
> > - "it's a longstanding tradition to support this"
> > - "it's really useful on my 386 SX with a 40 MB hard disk"
> 
> - NFS
> - for my wifi box (ie a 386 SX with 8MB of flash)

Interesting. I thought 386 wasn't supported anymore (?)
http://www.debian.org/releases/stable/i386/ch02s01.html.en#id2756691

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Guus Sliepen
On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote:

> So, does anybody still see reasons to continue supporting a standalone
> /usr?
> If you do, please provide a detailed real-world use case.
> A partial list of invalid reasons is:
> - "it's really useful on my 386 SX with a 40 MB hard disk"

How about a 486 with a 96 MB Disk-on-Chip module? I maintain one such computer
(it's a PC104 form factor machine), as well as a number of AMD Geodes (586)
with 256 MB CompactFlash cards. It is very useful for these sytems to have a
minimal and functioning root filesystem, but to mount /usr over NFS.

Also, thin clients without harddisks may have a small SSD or get an initrd with
a root filesystem from TFTP, but again mount a shared, possible read-only /usr
over NFS.

I have an EeePC 901 with root and /home on the first 4 GB SSD, and /usr on the
second 16 GB SSD. The /usr is mounted read-only, and only remounted read-write
when apt is running. I have this setup because the first SSD is slightly faster
than the second, and the large /usr disk allows me to have a very large
fraction of Debian installed.

That said, the choice to put a program in /bin or /usr/bin is quite arbitrary.
It would be nice if one could tell dpkg where to install a package (and its
dependencies) to.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature


Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Roger Leigh
On Tue, May 05, 2009 at 06:50:47PM +0200, Giacomo Catenazzi wrote:
> Roger Leigh wrote:
> > On Tue, May 05, 2009 at 05:41:06PM +0200, Stéphane Glondu wrote:
> >> Marco d'Itri a écrit :
> >>> I know that Debian supports this, but I also know that maintaning
> >>> forever large changes to packages for no real gain sucks.
> >>> A partial list of invalid reasons is: [...]
> >> How about: "my /usr is shared by many machines over NFS"?
> > 
> > That might have been a "traditional" reason for a shared /usr.
> > However, the package manager can't cope with this setup since
> > you have some components of a package installed locally and
> > some remotely for all systems using the "shared" part.  It's
> > an impossible situation to actually cater for in real life.
> > Has anyone ever actually *done* this?
> 
> So why we created /usr/share (and moved documentation) ?

Good question.  While it's nice to keep arch-indep and arch-dep
files separated, I have never seen any cases where the arch-indep
information is actually shared amongst architectures (except for
at the arch:all package level, of course).

> But also I don't think it is a problem sharing usr
> on multiple system with multiple configurations.

Keeping such as configuration updated would be hard, since
each system would have an independent dpkg state in /var
and different conffile state in /etc.  If you removed a
package on one system, it might purge files in use on
another, and if you install a package on one the conffiles
won't be installed on the others, etc..

> On non public working stations, one doesn't run randomly
> programs. If I installed mysql-server on a system,
> it will work on such system, but if I install on
> an other system, it work also on the other system,
> occupying only one instance.
> 
> I don't see problem from package management
> (also because we have a nullpotent dpkg), so
> we can upgrade from multiple system without problems.

I'm not sure I see how this would work; I'd like to see
some examples, especially WRT the simple problems I
outlined above.

> > Looking at GNU/Hurd, /usr is a symlink to /.  If we were to make
> > /usr non-separable, maybe this would be the way to go.
> 
> or plan9, which bind mount all /*/bin into the main /bin.
> I can live with such solution, but please allow us to use /usr
> in a different (maybe shared) partition.

The plan9 situation is truly wonderful, and one can only hope
that Linux can do this at some point in the future.  I know
we have unionfs and aufs, but I wouldn't trust them for this
just yet!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Roger Leigh
On Tue, May 05, 2009 at 06:49:47PM +0200, Josselin Mouette wrote:
> Le mardi 05 mai 2009 à 17:24 +0100, Roger Leigh a écrit :
> > That might have been a "traditional" reason for a shared /usr.
> > However, the package manager can't cope with this setup since
> > you have some components of a package installed locally and
> > some remotely for all systems using the "shared" part.  It's
> > an impossible situation to actually cater for in real life.
> > Has anyone ever actually *done* this?
> 
> Of course, you just need to think the image you actually update as a
> master image, after which it is replicated by any means necessary (be it
> systemimager or NFS).

Sure, but you effectively only have "one" master image.  You don't
have multiple users of /usr with differing /etc or /var.  They are
all kept in sync.  This kind of makes /usr redundant since it is
"sharable" but only among identical systems or else you will run
into problems.

> As for NFS, I’d use root NFS instead of complicating my life with two
> different methods for / and /usr, but I guess some are doing it this
> way.

On the compute cluster I helped set up for biological modelling, we
opted to use Debian Live images on the cluster.  It IIRC NFS mounts
a read-only cramfs filesystem and uses aufs on top of that.  There's
just the one big filesystem (plus some site-specific mounts for
shared data and a big scratch area all the nodes can access).  We
certainly saw no point in making just /usr mountable since you need
a matching rootfs to accompany it.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Matthew Johnson
On Tue May 05 20:07, Iustin Pop wrote:
> Scenarion A, desktop
>   - / on non-LVM, fixed size, as recovery from a broken LVM setup is way
>   harder if / is on LVM
>   - /usr on LVM, as it can grow significantly, and having it on LVM is
>   much more flexible

This is what I do on all of my machines

-- 
Matthew Johnson


signature.asc
Description: Digital signature


Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Holger Levsen
Hi,

On Dienstag, 5. Mai 2009, Marco d'Itri wrote:
> I have been told by upstream maintainers of one of my packages and by
> prominent developers of other distributions that supporting a standalone
> /usr is too much work and no other distribution worth mentioning does it
> (not Ubuntu, not Fedora, not SuSE).

besides that appearantly Ubuntu keeps supporting /usr, it's pointless to 
discuss this here. LSB which maintains FHS is the right place for this.

On Dienstag, 5. Mai 2009, Marco d'Itri wrote:
> > Could you elaborate on the kind of "large changes" there are in Debian
> > to support this?
> I'd rather not change subject.

And this is just hillarious. If you can't explain why, why bother?


regards,
Holger


signature.asc
Description: This is a digitally signed message part.


Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Steve Langasek
On Tue, May 05, 2009 at 09:11:05PM +0200, Bernd Zeimetz wrote:
> Marco d'Itri wrote:
> > On May 05, Bastien ROUCARIES  wrote:

> >> - NFS
> > This is not detailed.

> >> - for my wifi box (ie a 386 SX with 8MB of flash)
> > This is not real world.

> It is.

Not with Debian it isn't.  Debian hasn't worked on true-386 systems for
several releases.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Bernd Zeimetz
Marco d'Itri wrote:
> On May 05, Bastien ROUCARIES  wrote:
> 
>> - NFS
> This is not detailed.
> 
>> - for my wifi box (ie a 386 SX with 8MB of flash)
> This is not real world.

It is. But as it seems you're living on a different world, so better don't start
touching the real world where the rest of Debian lives in, kthnxgoodbye.


-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Iustin Pop
On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote:
> I have been told by upstream maintainers of one of my packages and by
> prominent developers of other distributions that supporting a standalone
> /usr is too much work and no other distribution worth mentioning does it
> (not Ubuntu, not Fedora, not SuSE).
> 
> I know that Debian supports this, but I also know that maintaning
> forever large changes to packages for no real gain sucks.
> 
> So, does anybody still see reasons to continue supporting a standalone
> /usr?
> If you do, please provide a detailed real-world use case.
> A partial list of invalid reasons is:
> - "I heard that this was popular in 1998"
> - "it's a longstanding tradition to support this"
> - "it's really useful on my 386 SX with a 40 MB hard disk"

Scenarion A, desktop
  - / on non-LVM, fixed size, as recovery from a broken LVM setup is way
harder if / is on LVM
  - /usr on LVM, as it can grow significantly, and having it on LVM is
much more flexible

Scenario B, laptop/netbook
  - / non-encrypted, small, asks for passphrase to boot
  - everything else on dm-crypt+lvm

This seems a very weird proposition to me. Separate /usr works, as is
more flexible: needed space for / is < 500MB, needed space for /usr is >
4GB.

regards,
iustin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Steve Langasek
On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote:
> I have been told by upstream maintainers of one of my packages and by
> prominent developers of other distributions that supporting a standalone
> /usr is too much work and no other distribution worth mentioning does it
> (not Ubuntu, not Fedora, not SuSE).

This is false for Ubuntu.  Not only is it supported, but significant effort
was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as
pertains to wpasupplicant.

> I know that Debian supports this, but I also know that maintaning
> forever large changes to packages for no real gain sucks.

What packages?

Any upstream not supporting this is also incompatible with the FHS.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread John H. Robinson, IV
Marco d'Itri wrote:
> I have been told by upstream maintainers of one of my packages and by
> prominent developers of other distributions that supporting a standalone
> /usr is too much work and no other distribution worth mentioning does it
> (not Ubuntu, not Fedora, not SuSE).

Do you mean that:
1) /usr is dedicated to the system, (NFS sharing /usr across multiple
   independent systems would be out)

 -or-

2) /usr is part of the root partition, much like how /lib is now.

The latter implies the former, of course.

The last time I installed Red Hat Enterprise Linux (which was RHEL 5.2)
I was still given the option of making a separate partition for /usr. I
have never installed Fedora or SuSE. The last time I installed Ubuntu
was multiple years ago, so I don't know what they are doing currently.

Thank you for clearing up this point of confusion.

-- 
John H. Robinson, IV  jaq...@debian.org
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Manoj Srivastava
On Tue, May 05 2009, Marco d'Itri wrote:

> On May 05, Stéphane Glondu  wrote:
>
>> Could you elaborate on the kind of "large changes" there are in Debian
>> to support this?
> I'd rather not change subject.

This is not a change of subject. You are starting a haevy duty
 thread about changing how Debian does things, you need to provide
 motivation for even thinking of this change. Why should we bother?

>> > A partial list of invalid reasons is: [...]
>> How about: "my /usr is shared by many machines over NFS"?
> Do you actually *do* this?

Sure.
> On how many systems?

About 30 or so.

> How do you manage upgrades?

I have nothing to manage. This is POSIX, after all. Once the
 partitions have been setup, what management is there to be done?

manoj
-- 
Marriage is a great institution -- but I'm not ready for an institution
yet. Mae West
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Lucas Nussbaum
On 05/05/09 at 17:58 +0200, Bastien ROUCARIES wrote:
> On Tue, May 5, 2009 at 5:43 PM, Marco d'Itri  wrote:
> > On May 05, Bastien ROUCARIES  wrote:
> >
> >> - NFS
> > This is not detailed.
> 
> /usr NFS shared. Scientific grid use this stuff and it is real world.
> But may be it is too big for debian ;)

Do you actually do this? On which grid/cluster?

> >> - for my wifi box (ie a 386 SX with 8MB of flash)
> > This is not real world.
> 
> I am not really sure that embeded development is not real world. And
> it will growth
> more than classical PC in the next ten year. Maybe too small for debian ;)

Have you compared the power consumption of your 386 SX with a more
modern system? 

Also, I doubt that you will run Debian squeeze on your 386 SX ;)
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: deprecating /usr as a standalone filesystem?

2009-05-05 Thread Giacomo Catenazzi
Roger Leigh wrote:
> On Tue, May 05, 2009 at 05:41:06PM +0200, Stéphane Glondu wrote:
>> Marco d'Itri a écrit :
>>> I know that Debian supports this, but I also know that maintaning
>>> forever large changes to packages for no real gain sucks.
>>> A partial list of invalid reasons is: [...]
>> How about: "my /usr is shared by many machines over NFS"?
> 
> That might have been a "traditional" reason for a shared /usr.
> However, the package manager can't cope with this setup since
> you have some components of a package installed locally and
> some remotely for all systems using the "shared" part.  It's
> an impossible situation to actually cater for in real life.
> Has anyone ever actually *done* this?

So why we created /usr/share (and moved documentation) ?

I see a lot of parallel installed system, so in this case
I see no problem on sharing /usr.
[BTW one of the most important conference is not LISA, about
such configurations?]

But also I don't think it is a problem sharing usr
on multiple system with multiple configurations.

On non public working stations, one doesn't run randomly
programs. If I installed mysql-server on a system,
it will work on such system, but if I install on
an other system, it work also on the other system,
occupying only one instance.

I don't see problem from package management
(also because we have a nullpotent dpkg), so
we can upgrade from multiple system without problems.


> Looking at GNU/Hurd, /usr is a symlink to /.  If we were to make
> /usr non-separable, maybe this would be the way to go.

or plan9, which bind mount all /*/bin into the main /bin.
I can live with such solution, but please allow us to use /usr
in a different (maybe shared) partition.

ciao
cate


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



  1   2   >