Hello
On Sat, Jun 21, 2003 at 01:12:20PM +0200, Thomas Hood wrote:
> Some progress has been made toward the goal of making
> Debian easier to use with a read-only root filesystem.
> Action has been taken to remove variable files from /etc/,
> or at least to make it possible to do so
you're likely to get much better results with a read-only
root if you use current versions of packages from unstable. You seem to
have found a way to resolve the issue with the Samba package, but in
unstable the issue should not have arisen: /etc/samba/MACHINE.SID has
been replaced by /var
Thomas Hood wrote:
>No need. It is sufficient that /tmp/ and /dev/ be separate, writable,
>filesystems. It is a local decision whether to make these tmpfs and
>devfs, respectively.
I've successfully run without a writeable dev but with devptsfs. How
much "writeability" is required depends on ho
On Jun 22, Xavier Roche <[EMAIL PROTECTED]> wrote:
>[2003/06/22 11:13:11, 0] passdb/pdb_smbpasswd.c:startsmbfilepwent(237)
> startsmbfilepwent_internal: failed to set 0600 permissions on password file
> /etc/samba/smbpasswd. Error was Read-only file system
> .unable to open passdb database.
On Jun 22, Xavier Roche <[EMAIL PROTECTED]> wrote:
>Dunno.. shall we consider devfs and tmpfs as standard (which is IMHO a
>good idea) for future releases?
For your ro-root system: definitely yes. For debian, don't dare.
--
ciao, |
Marco | [1679 corp.qbtCr/Hg]
On Jun 22, Thomas Hood <[EMAIL PROTECTED]> wrote:
>The question is: Should we concede that a separate /dev/ fs is
>required for running with a read-only root filesystem, or should we
>take steps to eliminate fiddling with /dev/ files? I haven't
Yes. Consoles *must*
t; > required for running with a read-only root filesystem
>
> Dunno.. shall we consider devfs and tmpfs as standard (which is IMHO a
> good idea) for future releases?
No need. It is sufficient that /tmp/ and /dev/ be separate, writable,
filesystems. It is a local decision
> Note that devfs is still "experimental" in 2.4
>
> Another remark for the HOWTO : mounting /tmp in "tmpfs" (since 2.4.1 ?)
> allows you not to resevre space for /tmp on a specific partition
>
> > The question is: Should we concede that a separate /dev/ fs is
&
ing locked out of my machine because
a read-only /dev prevented me logging in (login would complain about not
being able to change ownership).
> The question is: Should we concede that a separate /dev/ fs is
> required for running with a read-only root filesystem, or should we
> take steps to
mounting /tmp in "tmpfs" (since 2.4.1 ?)
allows you not to resevre space for /tmp on a specific partition
> The question is: Should we concede that a separate /dev/ fs is
> required for running with a read-only root filesystem
Dunno.. shall we consider devfs and tmpfs as standar
being fiddled. Obviously, one solution to the problem is
to have a separate writable /dev/ filesystem, e.g., devfs.
The question is: Should we concede that a separate /dev/ fs is
required for running with a read-only root filesystem, or should we
take steps to eliminate fiddling with /dev/ files? I
> this is not a problem due to devpts filesystem.
Okay, using devfs it works perfectly.
A remaining problem is also Samba:
[2003/06/22 11:09:07, 0] passdb/machine_sid.c:pdb_generate_sam_sid(85)
unable to open or create file /etc/samba/MACHINE.SID. Error was
Read-only file system
So actually s
On Sun, Jun 22, 2003 at 01:02:55AM +0200, Xavier Roche wrote:
> or /dev/pts/XX ownership depending on who is being
> logged in..
this is not a problem due to devpts filesystem.
It may be a problem for /dev/cdrom. You can ignore it (use a sane cdrom
group) or you can use dev filesystem.
For the
[I'm CC'ing to the debian-devel list]
Thomas Hood wrote:
>>Another small problem occurs when trying to keep /dev in ro:
>># /etc/init.d/sysklogd start
>>Starting system log daemon: syslogdchmod: changing permissions of
>>`/dev/xconsole': Read-only file system
>
> This occurs when /etc/init.d/sysk
[I hope I did not sent twice this mail]
> Packages that still employ variable files in /etc/ include:
> mount, ifupdown, dhcpcd, linuxlogo, ppp, util-linux.
> Fortunately, some of the files can be replaced by symlinks.
> See my README file at
> http://panopticon.csustan.edu/thood/readonly-root
> Packages that still employ variable files in /etc/ include:
> mount, ifupdown, dhcpcd, linuxlogo, ppp, util-linux.
> Fortunately, some of the files can be replaced by symlinks.
> See my README file at
> http://panopticon.csustan.edu/thood/readonly-root.html
> for (incomplete) information.
>
Some progress has been made toward the goal of making
Debian easier to use with a read-only root filesystem.
Action has been taken to remove variable files from /etc/,
or at least to make it possible to do so locally, in the
following packages: cupsys, laptop-net, pppconfig, sysvinit.
Packages
[/run/ and] read-only root
~~
The /run/ idea is shelved, unless someone wants to take up
the torch for it. Run-time state files moved out of /etc/ will
have to go into /var/run/. The program, therefore, is:
1. Wherever possible, state files in /etc/ should be eliminated
On Wed, 2003-04-30 at 15:13, Arthur de Jong wrote:
> I think it should be possible for any program that writes to /etc (it it
> cannot use /var) either to be configurable to store it's data somewhere
> else or use a symlink to store the data somwhere else (e.g. /proc/flashrom
> or /nfsmounteddiskbu
On Wed, Apr 30, 2003 at 03:13:43PM +0200, Arthur de Jong wrote:
> > Do you think having programs write to /etc is a bad thing?
> I think creating /run is worse.
> I think it should be possible for any program that writes to /etc (it it
> cannot use /var) either to be configurable to store it's d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I don't know what it will take to convince you, but I would like you to
> answer these questions:
I also have a problem with adding another toplevel directory and I suspect
there are some more. I haven't read the complete thread (I also have other
Whether we end up with "/run/, resolvconf and read-only root"
depends a lot on whether the maintainers of the affected packages
support the project. So far the response has not been positive.
Here is a quick summary for the packages that were on my TODO list.
Creating /run/
On Apr 29, Jamie Wilkinson <[EMAIL PROTECTED]> wrote:
>Do you think having programs write to /etc is a bad thing?
Yes.
>Where would you put /etc/mtab, to keep /etc sacrosanct?
I would teach mount to follow the /etc/mtab. Actually, I remember that
somebody already did this as he wrote about it o
a) The use case that motivate this proposal:
The debian-devel mailing list,
From: Thomas Hood <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
Subject: Re: /run/, resolvconf and read-only root
I would also suggest expanding on these, and presenting a
This one time, at band camp, Jamie Wilkinson wrote:
>This one time, at band camp, Theodore Ts'o wrote:
>>... and those who have tried to explain why it's a bad idea or have
>>concerns have been brushed off. So I've given up for now trying to
>>explain to you folks why I'm not convinced, since I do
This one time, at band camp, Theodore Ts'o wrote:
>... and those who have tried to explain why it's a bad idea or have
>concerns have been brushed off. So I've given up for now trying to
>explain to you folks why I'm not convinced, since I don't have time to
>go pig mud-wrestling, but please don't
On Mon, Apr 28, 2003 at 06:09:10PM -0400, Sam Hartman wrote:
> OK, I think my worst fears are realized. You do actually want to
> solve all the goals I could have imagined you possibly wanting to try
> try and solve.
>
> I think I am very likely to wait until there is a policy change or at
> leas
specific goal, I'm
> >> unlikely to accept such changes if they are submitted to me.
> >> As a maintainer I want to be able to look at some statement and
> >> answer the following questions:
>
> Jamie> Hi Sam,
>
> Jamie> I've ju
OK, I think my worst fears are realized. You do actually want to
solve all the goals I could have imagined you possibly wanting to try
try and solve.
I think I am very likely to wait until there is a policy change or at
least text that would be good guidelines as a policy change before
implementi
to me.
>> As a maintainer I want to be able to look at some statement and
>> answer the following questions:
Jamie> Hi Sam,
Jamie> I've just filed the bug with my patch to pam. My goal is
Jamie> not specifically a read-only root (although that may be a
On Mon, 2003-04-28 at 00:01, Sam Hartman wrote:
> 1) Why are people mounting root read-only?
"Frank" (Not his real name) has a machine with a local
read-only boot medium and a network connection but no local
hard disk.
"Jane" finds it nice that her /etc/ hierarchy changes only
when she administer
#x27;ve just filed the bug with my patch to pam. My goal is not specifically a
read-only root (although that may be a useful by-product of it) but just to
remove any program state out of /etc. It is my firm belief that programs
should not be writing anything to /etc.
The patch against pam doesn&#x
Hi.
I noticed that in order to implement your read-only root proposal, you
propose to modify the pam package.
I'm not really sure I see the justification for read-only /. I can
see several possible justifications and some of the possible goals
conflict.
Until you get general consensus
This message is about three interdependent goals:
1. To create /run/, which makes it possible ...
2. to implement variable resolver configuration, which will help
3. to make it possible to mount / read-only.
(In the present context, "variable" information is information
that changes during the no
I think I should perhaps put on a flak jacket before suggesting this.
Perhaps it'd be a good idea to list the directories which we intend
to support on a read-only root, and have packages migrate file
permissions for files installed in these directories to read-only.
Noncompliant packages
35 matches
Mail list logo
