> > ; mntgen a
> > ; bind /env a/env
> > ; bind /bin a/bin
> > ; bind /proc a/proc
> > ; bind a /
> > ; ns
> >
> > consider it a security feature.
>
> Be it as it may, I still can't quite follow why *manual* pruning
> of the entries from the namespace would be forbidden. u
> aha, I didn't understand what "bootes" was for. In any case, when I
> first booted the cpu/auth server, I was asked for authid (is this the
> same as the hostid you mention?), authdom (I don't get to what this
> domain applies, incoming requests to the auth server?) secstore key
> (dunno) and pas
simliar story here, lost disk, lost data. In this case because I made
a mistake.
I've been wondering -- how much of your file systems are you using out there?
Seems to me that one could build a fanless wonder with a small via
embedded system and USB sticks -- 3 of them -- as the disks, running
in
back when i had mirroring via devfs (some three years ago now) i used
'cmp' to verify that the disks were being correctly written to and
that no errors have occurred. i ran cmp from the nigtly log at least
couple of times a week.
Hi,
I guess that this must be a FAQ; but I've already spent days googling,
reading docs, man pages, etc. and I'm still lost.
Short background: I'm an experienced (11y) Linux sysadmin, but this is
the first time I try to delve into Plan9. I want to play with it and
to explore it's possibilities in
we have three different console servers at coraid.
so i've changed how consoles and console logging
works. maybe this will be useful to other people.
here are the changes that make this work
1. instead of consoledb use /lib/ndb/consoledb.$sysname.
and have a general test for this new file in cpur
> back when i had mirroring via devfs (some three years ago now) i used
> 'cmp' to verify that the disks were being correctly written to and
> that no errors have occurred. i ran cmp from the nigtly log at least
> couple of times a week.
that's a good idea.
when using the mirror device, no write
>From the docs, isn't it supposed to be unusable from the console? Or this
>is just a relic and now any system can be a file server?
that's a different, older implementation of file service, using its own kernel;
it's described by fs(4).
it is still separately available and maintained, but the .i
* Fco. J. Ballesteros <[EMAIL PROTECTED]> [081015 10:42]:
> We use aux/clog to send the contents of /dev/kprint to /sys/log/$sysname
> We bind '#k' by hand after booting our server, but how you do it it depends
> on the particular config for your machine.
>
As it has been I placed the fs= line in
All the output sent to the console is available via /dev/kprint.
If you copy that file somewhere, eg, using aux/clog, all your messages
should be in that file.
> From: [EMAIL PROTECTED]
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Wed Oct 15 10:48:09 CET 2008
> Subject: Re: [9fan
On Wed, Oct 15, 2008 at 07:22, Steve Simon <[EMAIL PROTECTED]> wrote:
> The system hangs together through an auth system which is distantly related
> to kerberos.
>
> the file servers and auth servers share a host ID and password, by convention
> the name
aha, I didn't understand what "bootes" w
Dear List,
I have experienced a disk crash in a mirrored fs(3). It turned out
that the mirroring has not been successful since December 2007 which
is quite a loss for me now.
To prevent a case like this it would have helped If I had seen the
error messages by fs(3) earlier/at all. By browsing thr
On Mon, 2008-10-13 at 18:35 -0400, erik quanstrom wrote:
> > 4) What is the sense of
> > bind 'sth' 'the_same_sth'
> > ? (like 'bind / /' or 'bind /usr/ruda/a /usr/ruda/a')
>
> i believe this is a noop. in the case of "bind / /", look
> at /lib/namespace. consider the case where $rootdir
> isn't
We use aux/clog to send the contents of /dev/kprint to /sys/log/$sysname
We bind '#k' by hand after booting our server, but how you do it it depends
on the particular config for your machine.
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Reply-To: 9fans@9fans.net
> Date: Wed Oct 15 10:31
* erik quanstrom <[EMAIL PROTECTED]> [081015 18:23]:
> > back when i had mirroring via devfs (some three years ago now) i used
> > 'cmp' to verify that the disks were being correctly written to and
> > that no errors have occurred. i ran cmp from the nigtly log at least
> > couple of times a week.
Hi,
I am trying to work with files containing whitespace,
many programs in plan9 are happy with this but sam and B
don't appear to be (unless I have broken somthing).
I can fix the buglet in B (some string flattening) but
a cursory look at the sam source and it seems to support
delimiters in comm
The system hangs together through an auth system which is distantly related to
kerberos.
the file servers and auth servers share a host ID and password, by convention
the name
is "bootes". the username and password is stored in a tiny partition on the
disk (nvram partition).
this allows them to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 15, 2008, at 8:10 AM, Charles Forsyth wrote:
(i think venti is optional but i might be wrong.)
Yes, it's optional.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkj2VAwACgkQuv7AVNQDs+xZgACdEsgJT4PaatwcH7wlL6Qm/H6
On Wed, Oct 15, 2008 at 11:55, Steve Simon <[EMAIL PROTECTED]> wrote:
> Sounds like you understand quite well really, I think you
> are further up the learning curve than you think.
Well, it seems that I wasn't so far away, now I'm happily running a
cpu/auth/file server and many disk-less termina
On Wed, Oct 15, 2008 at 1:54 PM, Martín Ferrari
<[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 11:55, Steve Simon <[EMAIL PROTECTED]> wrote:
>
>> Sounds like you understand quite well really, I think you
>> are further up the learning curve than you think.
>
> Well, it seems that I wasn't so
On Wed Oct 15 14:38:47 EDT 2008, [EMAIL PROTECTED] wrote:
> [...] An interesting thing in my case
> is that I got cmp errors from the start, even with freshly nulled
> partitions and identical partitions and disks. I still cannot figure
> out why.
were these cmp errors in any particular place on t
21 matches
Mail list logo