This one time, at band camp, [EMAIL PROTECTED] wrote:
>Sorry to reopen this at such a late date, but I'm way behind on -devel.
>
>"Hi, I'm Karl and I maintain login and passwd."
>
>Thomas Hood <[EMAIL PROTECTED]> writes:
>> * pam, shadow
>> Allow either /etc/nologin or /run/nologin to preve
This one time, at band camp, Steve Langasek wrote:
>Shell pseudocode was posted to this thread (a month ago?) that showed
>how the init scripts could handle the requirement that /run be mounted
>early, even if it's not on the root fs. The init scripts already
>include special handling of /proc and
On Mon, Apr 28, 2003 at 11:35:58PM +0200, Thomas Hood wrote:
> On Mon, 2003-04-28 at 18:30, [EMAIL PROTECTED] wrote:
> > It would also be nice to have some blessing of /run in the policy first,
> > but that doesn't seem terribly likely.
>
> What is more important for now is whether there is broad
On Mon, 2003-04-28 at 18:30, [EMAIL PROTECTED] wrote:
> I don't like the idea of having multiple files to turn off logins. (I
> can't log into my system, and /etc/nologin doesn't exist! What? didn't you
> know about this *other* file?) I also don't want to solve this with a
> symlink.
Yes, let's
Sorry to reopen this at such a late date, but I'm way behind on -devel.
"Hi, I'm Karl and I maintain login and passwd."
Thomas Hood <[EMAIL PROTECTED]> writes:
> * pam, shadow
> Allow either /etc/nologin or /run/nologin to prevent non-root logins
I don't like the idea of having multiple
On Mon, Apr 28, 2003 at 06:50:15PM +1000, Jamie Wilkinson wrote:
> This one time, at band camp, Thomas Hood wrote:
> >Jamie Wilkinson wrote:
> >> That is right! The core of the matter is not whether
> >> filesystems need to be mounted over the network or not,
> >> but whether the parts of the file
This one time, at band camp, Thomas Hood wrote:
>Jamie Wilkinson wrote:
>> That is right! The core of the matter is not whether
>> filesystems need to be mounted over the network or not,
>> but whether the parts of the filesystem you are attempting
>> to write to are on the root filesystem or not.
This one time, at band camp, Marco d'Itri wrote:
>On Apr 07, Thomas Hood <[EMAIL PROTECTED]> wrote:
>
> >(I forgot to mention) J.W.'s patch does more than what a mere symlink
> >would do. By making programs sensitive both to /run/nologin and
> >/etc/nologin, it becomes possible for the administra
This one time, at band camp, Marco d'Itri wrote:
> >/etc has a "static nature". See the note on /etc/mtab under Table
> >3.7.3.1. It is also for configuration files. /etc/adjtime is neither.
>Then propose to change FHS.
Welcome to the discussion.
--
[EMAIL PROTECTED]
Jamie Wilkinson wrote:
> That is right! The core of the matter is not whether
> filesystems need to be mounted over the network or not,
> but whether the parts of the filesystem you are attempting
> to write to are on the root filesystem or not.
The essence of /run/ had better not include that it
This one time, at band camp, Thomas Hood wrote:
> * base-files
> Add /run/ directory
#191036: create /run for programs that run before /var is mounted
> * pam, shadow
> Allow either /etc/nologin or /run/nologin to prevent nonroot login
#191037: Allow both /etc/nologin and /run/nolo
This one time, at band camp, Thomas Hood wrote:
>(Re: /etc/nologin)
>> A dangling symlink should be considered like a missing file.
>
>Yes, that would work. However, having separate /etc/nologin
>and /run/nologin looks like a useful feature, as I mentioned
>earlier.
For clarification, (and this i
This one time, at band camp, Thomas Hood wrote:
>On Sat, 2003-04-12 at 10:12, Anthony DeRobertis wrote:
>> On Wed, 2003-04-09 at 14:17, Thomas Hood wrote:
>> > * ppp
>> > * Change /usr/sbin/pppd to:
>> > * Store PID in /run/, not in /var/run/
>> Why? Is the goal to make PPP-mounter /var
This one time, at band camp, Marco d'Itri wrote:
>On Apr 07, Thomas Hood <[EMAIL PROTECTED]> wrote:
>
> > * pam, shadow
> > Allow either /etc/nologin or /run/nologin to prevent non-root logins
>Use a symlink.
>
> > * util-linux
> > Use /run/mtab for mount's statefile
>Use a symlink.
A
This one time, at band camp, Anthony DeRobertis wrote:
>On Wed, 2003-04-09 at 14:17, Thomas Hood wrote:
>> The proposed new directory is for files similar to those in /var/run/
>> that are not just variable and unshareable but also local -- i.e., they
>> must be writable independently of network co
This one time, at band camp, Marco d'Itri wrote:
>On Apr 07, Steve Langasek <[EMAIL PROTECTED]> wrote:
>
> >Duh. Did you miss the part where people were talking about *amending the
> >FHS because the FHS is flawed*?
>Yes: I did not agree with them.
>And looks like I was right, because as I showed
This one time, at band camp, Blars Blarson wrote:
>In article <[EMAIL PROTECTED]>
>[EMAIL PROTECTED] writes:
>>I won't debate whether this is true in general, bug it is certainly
>>unnecessary in the case of pump. I have specifically added code to
>>deal with the inability to write to /var/run by
On Tue, 2003-04-15 at 15:19, Thomas Hood wrote:
> Unfortunately you seem to be wrong, at least with regard to
> bind version 1:8.3.4-4.
Ah. That'd explain it. I'm using bind9.
signature.asc
Description: This is a digitally signed message part
On 8 April 2003 "Marco d'Itri" <[EMAIL PROTECTED]> wrote:
> On Apr 07, Thomas Hood <[EMAIL PROTECTED]> wrote:
>>A difficulty is that only a whole "options { ... };"
>>statement can be included from the named configuration file,
>>not just the "forwarders { ... };" statement inside it.
>
>You can in
On Thu, Apr 10, 2003 at 07:27:42PM -0400, Jeremy Jackson wrote:
> Overall I think it is wonderful to see support for read-only root being
> worked on.
>
> On Wed, 2003-04-09 at 15:41, Matthew Garrett wrote:
> > Jeremy Jackson wrote:
> >
> > (doing this with bind mounts)
> >
> > >2.2 kernels are
Thomas Hood <[EMAIL PROTECTED]> wrote:
>
> Unnecessary; but would using /run for the pidfile be a better
> (e.g., simpler) solution?
>
> If not then do you think the TCP-socket approach is the way
> to deal with every program that writes a pidfile when /var/
> may be absent?
Pump doesn't write p
On Sat, 2003-04-12 at 10:12, Anthony DeRobertis wrote:
> On Wed, 2003-04-09 at 14:17, Thomas Hood wrote:
> > * ppp
> > * Change /usr/sbin/pppd to:
> > * Store PID in /run/, not in /var/run/
> Why? Is the goal to make PPP-mounter /var to work?!
I suppose someone might want to mount /var
On Sat, 2003-04-12 at 23:56, Herbert Xu wrote:
> >> * Change /sbin/pump to:
> >> * Store PID in /run, not in /var/run
> I won't debate whether this is true in general, bug it is certainly
> unnecessary in the case of pump. I have specifically added code to
> deal with the inability to w
Blars Blarson <[EMAIL PROTECTED]> wrote:
>
> It will also need to cope with writing to /var/run on the root
> partition, having /var mounted, and later processes not being able to
> open the file since the /var/run directory on the root disk is
> inaccessable.
It does. If the Unix-domain socket
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>I won't debate whether this is true in general, bug it is certainly
>unnecessary in the case of pump. I have specifically added code to
>deal with the inability to write to /var/run by making pump fall back
>to using TCP sockets.
It will
Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
>
>> * pump
>> * Add /etc/pump directory
>> * Change /sbin/pump to:
>> * Store PID in /run, not in /var/run
>
> Quite. Programs in /sbin shouldn't, in general, be using /var/run.
I won't debate whether this is true in general, bug it
On Wed, 2003-04-09 at 14:17, Thomas Hood wrote:
> * ppp
> * Change /usr/sbin/pppd to:
> * Store PID in /run/, not in /var/run/
Why? Is the goal to make PPP-mounter /var to work?! If so, pppd has to
be moved to /sbin.
> * pump
> * Add /etc/pump directory
> * Change /sbin/pum
On Wed, 2003-04-09 at 10:13, Marco d'Itri wrote:
> >Leaving /etc/adjtime as is and telling admins to "move it and use a
> >symlink" is a FHS violation because /etc/adjtime is.
> What part of "FHS does not apply to local changes" you did not
> understand?
No part. Please read my message again. T
(I am resending this because the earlier version contained
a few minor errors. I suppose I should put this on the web
somewhere and post the link.)
(I repeat the call for people to look for files that are in
/etc/ but shouldn't be.)
Here are:
* an updated list of wishes filed,
* an updated TODO
* Jeremy Jackson <[EMAIL PROTECTED]> [030410 23:59]:
> Can someone point me the message(s) discussing /run (and why not
> /etc/run) - I would like to think that adding another directory off /
> should be avoided. /etc/run sounds nice, unless you want to support
> booting before /etc is mounted...
Overall I think it is wonderful to see support for read-only root being
worked on.
On Wed, 2003-04-09 at 15:41, Matthew Garrett wrote:
> Jeremy Jackson wrote:
>
> (doing this with bind mounts)
>
> >2.2 kernels are out though.
>
> As are BSDs. I have no idea whether the Hurd supports bind mounti
Can someone point me the message(s) discussing /run (and why not
/etc/run) - I would like to think that adding another directory off /
should be avoided. /etc/run sounds nice, unless you want to support
booting before /etc is mounted...
Cheers,
Jeremy
On Wed, 2003-04-09 at 14:17, Thomas Hood wr
On Wed, 2003-04-09 at 20:22, Jeremy Jackson wrote:
> Clearly what is needed here is an API for resolver updates
> [...]
What you describe is roughly what I wrote up in my last TODO
message.
> In Debian, there should possibly be a policy decided upon.
> (what the dir is, what API is, etc)
I don't
33 matches
Mail list logo
