Re: [9fans] 4th edition file server available

Re: [9fans] 4th edition file server available

[okamoto]

> I wonder, fossil, why so geological name?

 From a view point of geologist, I suppose fossil is not so 'geologic'
name.  ?

Kenji

Re: [9fans] 4th edition file server available

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 92 bytes --]

It has both the letters f and s in it, was in out dictionary,
and has a feel of permanence.

[-- Attachment #2: Type: message/rfc822, Size: 1415 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 4th edition file server available
Date: Tue, 14 Jan 2003 15:06:04 +0900
Message-ID: <e5fcb3c136701335102b6f15dc0c2525@granite.cias.osakafu-u.ac.jp>

> I wonder, fossil, why so geological name?

 From a view point of geologist, I suppose fossil is not so 'geologic'
name.  ?

Kenji

Re: [9fans] 4th edition file server available

[Andrey S. Kukhar]

dictionary-translator said me that this is geologic 
word (e.g., in expression ``useful fossils''). 
It`s not right?

-kyxap

> From a view point of geologist, I suppose fossil is not
> so 'geologic' name.  ?
>
> Kenji

Re: [9fans] 4th edition file server available

[Andrey S. Kukhar]

I wonder, fossil, why so geological name?

-kyxap

Re: [9fans] 4th edition file server available

[Russ Cox]

> An excellent policy, which also helps in importing software
> from other systems.  Standards have a purpose.

as i wrote that, i suspected you would approve.

Re: [9fans] 4th edition file server available

[Douglas A. Gwyn]

Russ Cox wrote:
> we left strncat alone to avoid surprises when porting plan 9
> code to other systems.

An excellent policy, which also helps in importing software
from other systems.  Standards have a purpose.

Re: [9fans] 4th edition file server available

[Russ Cox]

> Miller, T. C., Raadt, T. D.
> strlcpy and strlcat -- Consistent, Safe, String Copy and Concatenation.
> Proceedings of USENIX Annual Technical Conference. June,
> 1999. http://www.openbsd.org/papers/strlcpy-paper.ps

surely this is near the top of the list for most trivial usenix paper ever.

> on the other hand I think we're in the unique position to fix strncpy
> instead of adding another syscall

strecpy serves a similar purpose.

we left strncat alone to avoid surprises when porting plan 9
code to other systems.

Re: [9fans] 4th edition file server available

[andrey mirtchovski]

or, we can just avoid it altogether...

s/Ken C/ANSI C/ in the previous email

andrey

Re: [9fans] 4th edition file server available

[Russ Cox]

g% pull
c sys/src/cmd/cpu.c
c 386/bin/cpu
g% 

g% cpu -h `{perl -e 'print "a"x1000'}
cpu: can't dial: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 aaaaaaaaaaaaaaaaaaaaaaaaaaa: cs: can't translate address
g% 

Re: [9fans] 4th edition file server available

[andrey mirtchovski]

I agree, this opens up a whole new can of worms, as illustrated here:

Miller, T. C., Raadt, T. D.
strlcpy and strlcat -- Consistent, Safe, String Copy and Concatenation.
Proceedings of USENIX Annual Technical Conference. June,
1999. http://www.openbsd.org/papers/strlcpy-paper.ps

on the other hand I think we're in the unique position to fix strncpy
instead of adding another syscall -- after all it's not Ken C we're
dealing with :)

andrey

On Tue, 14 Jan 2003, Scott Schwartz wrote:

> Andrey writes:
> | <               strncpy(system, p, sizeof system);
>
> That still has the problem that strncpy is not required to NUL terminate
> the destination.  How about strecpy?
>

Re: [9fans] 4th edition file server available

[Scott Schwartz]

Andrey writes:
| <               strncpy(system, p, sizeof system);

That still has the problem that strncpy is not required to NUL terminate
the destination.  How about strecpy?

Re: [9fans] 4th edition file server available

[Skip Tavakkolian]

> It has both the letters f and s in it, was in out dictionary,
> and has a feel of permanence.

It is efficient by being skeletal?

Re: [9fans] 4th edition file server available

[andrey mirtchovski]

On Mon, 13 Jan 2003, Russ Cox wrote:

> There are no buffer overflows anyway.  ;-)


I see the smiley, but have to reply anyway. this is not a nasty jab
at Russ, just a fix (I hope :)

there's a buffer overflow in cpu.c (strcpy):

% cpu -h `{perl -e '{print "A"x100;}'}
cpu 116986: suicide: sys: trap: fault read addr=0x19000 pc=0x00005b8b
plan9% acid 116986
/proc/116986/text:386 plan 9 executable

/sys/lib/acid/port
/sys/lib/acid/386
acid: stk()
At pc:0x00005b8b:fmtfmt+0x1f /sys/src/libc/fmt/fmt.c:63
fmtfmt(c=0x00000073) /sys/src/libc/fmt/fmt.c:57
        called from _fmtdispatch+0x83 /sys/src/libc/fmt/fmt.c:175
_fmtdispatch(isrunes=0x00000000,f=0x7fffeb48,fmt=0x000168b6) /sys/src/libc/fmt/fmt.c:113
        called from dofmt+0x75 /sys/src/libc/fmt/dofmt.c:62
dofmt(fmt=0x000168b4,f=0x7fffeb48) /sys/src/libc/fmt/dofmt.c:7
        called from vsnprint+0x62 /sys/src/libc/fmt/vsnprint.c:20
vsnprint(len=0x00000100,buf=0x00018734,args=0x7fffebac,fmt=0x000168b0) /sys/src/libc/fmt/vsnprint.c:5
        called from snprint+0x2b /sys/src/libc/fmt/snprint.c:13
snprint(fmt=0x000168b0,buf=0x00018734,len=0x00000100) /sys/src/libc/fmt/snprint.c:5
        called from netmkaddr+0x5e /sys/src/libc/port/netmkaddr.c:34
netmkaddr(linear=0x00017e0c,defnet=0x00000000,defsrv=0x00016978) /sys/src/libc/port/netmkaddr.c:10
        called from rexcall+0x28 /sys/src/cmd/cpu.c:347
rexcall(host=0x00017e0c,service=0x00016978,fd=0x7fffed98) /sys/src/cmd/cpu.c:339
        called from main+0x132 /sys/src/cmd/cpu.c:147
main(argv=0x7fffef84,argc=0x00000000) /sys/src/cmd/cpu.c:77
        called from _main+0x31 /sys/src/libc/386/main9.s:16
acid:


----------------------

here's the fix:

plan9% diff cpu.c /sys/src/cmd/cpu.c
121c121
<               strncpy(system, p, sizeof system);
---
>               strcpy(system, p);
plan9% 8c cpu.c; 8l cpu.8
plan9% 8.out -h `{perl -e '{print "A"x100}'}
cpu: can't dial: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA: cs: can't translate address
plan9%

Re: [9fans] 4th edition file server available

[rob pike, esq.]

[-- Attachment #1: Type: text/plain, Size: 135 bytes --]

A less drastic step would be to disable network ports such as
cpu and telnet, to require people to use the console to debug.

-rob

[-- Attachment #2: Type: message/rfc822, Size: 1972 bytes --]

From: Richard Miller <miller@hamnavoe.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 4th edition file server available
Date: Mon, 13 Jan 2003 10:01:30 0000
Message-ID: <14897aa3a24d632f340f30863deb7850@hamnavoe.demon.co.uk>

> One advantage (as I understood it) of using a specialized kernel
> was a form of security -- there were *no* user mode programs
> whose bugs could be exploited.

It went further than that: you couldn't even exploit a buffer overflow
to exec a shell, because there was no shell and no exec.

Would it be feasible, as part of bootstrapping a minimal fossil
server, to remove or otherwise disable the exec system call
once everything was running?

-- Richard

Re: [9fans] 4th edition file server available

[Russ Cox]

> Would it be feasible, as part of bootstrapping a minimal fossil
> server, to remove or otherwise disable the exec system call
> once everything was running?

Of course.  Go ahead if you really want.  I don't want to live
in that environment.  There are no buffer overflows anyway.  ;-)
I _really_ like the fact that I can run other programs on
the file server now, like flchk.  I'm not going back.

I think it's reasonable not to run any services on the
machine other than fossil, and to connect with a serial
console to run other things.  Disabling exec strikes me
as extreme.

Re: [9fans] 4th edition file server available

[Richard Miller]

> One advantage (as I understood it) of using a specialized kernel
> was a form of security -- there were *no* user mode programs
> whose bugs could be exploited.

It went further than that: you couldn't even exploit a buffer overflow
to exec a shell, because there was no shell and no exec.

Would it be feasible, as part of bootstrapping a minimal fossil
server, to remove or otherwise disable the exec system call
once everything was running?

-- Richard

Re: [9fans] 4th edition file server available

[jmk]

On Sat Jan 11 21:37:18 EST 2003, joelcsalomon@excite.com wrote:
> 
> >It is a user-level program rather than a special kernel
> One advantage (as I understood it) of using a specialized kernel was a form of security -- there were *no* user mode programs whose bugs could be exploited. How "standalone" can a Fossil/Venti server be? Can I delete almost everything in /bin to "lock down" the system?
> 
> --Joel

The intent is that it should be possible to configure the system
via the kernel config such that the only process(es) running are
those necessary to run a fileserver, i.e. fossil and factotum, with
only a physical console for control. The less paranoid you are, the
more user level stuff you can leave running, e.g. starting fossil
from /bin/cpurc.

Of course, we're nowhere near there yet.

--jim

[9fans] 4th edition file server available

[Joel Salomon]

>It is a user-level program rather than a special kernel
One advantage (as I understood it) of using a specialized kernel was a form of security -- there were *no* user mode programs whose bugs could be exploited. How "standalone" can a Fossil/Venti server be? Can I delete almost everything in /bin to "lock down" the system?

--Joel



_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

Re: [9fans] 4th edition file server available

[Russ Cox]

the credit for fs(3) goes to nemo, by the way.

Re: [9fans] 4th edition file server available

[rog]

> /sys/doc/fossil.pdf mentions an ``experimental file stack device'' devfs(3).
> I'm just curious; is that man page available?
> (could not find on plan9 web nor on sources)

it's a mistake in the paper.
see instead fs(3).

Re: [9fans] 4th edition file server available

[Axel Belinfante]

/sys/doc/fossil.pdf mentions an ``experimental file stack device'' devfs(3).
I'm just curious; is that man page available?
(could not find on plan9 web nor on sources)

Axel.

Re: [9fans] 4th edition file server available

[Fco.J.Ballesteros]

> You could
> back up Venti to a WORM drive, I suppose.

An alternate way would be to use fs(3) to setup a mirror
for your venti.

Re: [9fans] 4th edition file server available

[Russ Cox]

There is no support for WORM devices.
The WORM is replaced by Venti.  You could
back up Venti to a WORM drive, I suppose.

Re: [9fans] 4th edition file server available

[Andrew]

Maybe this is in the doc's somewhere, but just do i know ahead of time,
does fossil have support for worm devices, ie HP optical jukeboxes and
such? thanks

Andrew

Re: [9fans] 4th edition file server available

[Russ Cox]

> Does this mean we don't need il protocol anymore?

Correct.

Re: [9fans] 4th edition file server available

[Russ Cox]

> will you put a link to it on http://plan9.bell-labs.com/sys/doc/index.html
> (the index page for Volume 2 documents) or it's not yet supposed to be
> read by third parties?

I'm not sure it's quite ready for that.

Re: [9fans] 4th edition file server available

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Not to fossil, but we're using this to move our worm into vac, which
can be serviced by venti. 9fs automates it for us.

#!/bin/rc
# mkvac: creates one vac archive. argument is day number.
#

srv -q il!sargazos.escet.urjc.es
mount /srv/il!sargazos.escet.urjc.es /n/dump dump
date
vname=`{echo $1 | sed 's|/|_|g'}
lname=`{cat mkvac.last}
echo vac -s -b16k -f dump/2002/$vname.vac -d dump/2002/$lname -q /n/dump/$1
time vac -s -b16k -f dump/2002/$vname.vac -d dump/2002/$lname -q /n/dump/$1
echo echo $vname.vac '>' mkvac.last
 echo $vname.vac > mkvac.last
unmount /n/dump
rm /srv/il!sargazos.escet.urjc.es
date


This other one calls the previous one to automate it:
#!/bin/rc
days=(0508 0507 0506 .....other preferred days here)
for (d in $days) {
	cp /dev/text /n/once/nemo/mkvacs.out
	echo -n $d starts ' '
	mkvac 2002/$d
	echo
}
exit


We are doing 1.5 months per day or so.

[-- Attachment #2: Type: message/rfc822, Size: 3844 bytes --]

From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 4th edition file server available
Date: Wed, 08 Jan 2003 12:09:07 +0100
Message-ID: <200301081109.h08B97629776@zamenhof.cs.utwente.nl>

Congratulations!

I feel a bit adventurous -- but also in the need of
a little (or more?) hand-holding.

I have browsed through the setting up docs on wiki,
and a couple of the refered man pages, but
could not easily see how to build a fossil from
(to replace) an existing fake-worm file server,
taking into account the dump partition.

I recall reading before that at bell labs worm
disks of the fs were copied ``by hand'' one by one,
by taking them out of the fs.
Is there a way to transfer dump to fossil from
a running fake-worm fs (so, just using normal 9p
access, without going to the ``raw disks'')?

On a related note: my fake-worm fs uses relatively small
blocks (4Kb). Can I freely choose a block size for the
venti underlying the fossil, or should there be
a strict relation between the fake-worm  block size
and the fossil/venti block size (e.g. due to transfer
of dump blocks)?

Thanks for any insight (pointers welcome),
Axel.

> The new 4th edition file server, named Fossil,
> is now available on sources.  There are some
> how-to docs for setting up Venti and Fossil at:
[snip] 
> It is still a work in progress, but it's ready to be used
> by those feeling adventurous.

Re: [9fans] 4th edition file server available

[andrey mirtchovski]

will you put a link to it on http://plan9.bell-labs.com/sys/doc/index.html
(the index page for Volume 2 documents) or it's not yet supposed to be
read by third parties?

thanx, andrey

On Wed, 8 Jan 2003, Russ Cox wrote:

> The man pages fossil(4) and fossilcons(8) are
> the definitive reference.  /sys/doc/fossil.pdf (aka
> http://plan9.bell-labs.com/sys/doc/fossil.pdf)

Re: [9fans] 4th edition file server available

[Axel Belinfante]

Congratulations!

I feel a bit adventurous -- but also in the need of
a little (or more?) hand-holding.

I have browsed through the setting up docs on wiki,
and a couple of the refered man pages, but
could not easily see how to build a fossil from
(to replace) an existing fake-worm file server,
taking into account the dump partition.

I recall reading before that at bell labs worm
disks of the fs were copied ``by hand'' one by one,
by taking them out of the fs.
Is there a way to transfer dump to fossil from
a running fake-worm fs (so, just using normal 9p
access, without going to the ``raw disks'')?

On a related note: my fake-worm fs uses relatively small
blocks (4Kb). Can I freely choose a block size for the
venti underlying the fossil, or should there be
a strict relation between the fake-worm  block size
and the fossil/venti block size (e.g. due to transfer
of dump blocks)?

Thanks for any insight (pointers welcome),
Axel.

> The new 4th edition file server, named Fossil,
> is now available on sources.  There are some
> how-to docs for setting up Venti and Fossil at:
[snip] 
> It is still a work in progress, but it's ready to be used
> by those feeling adventurous.

Re: [9fans] 4th edition file server available

[okamoto]

> there are many other differences.  It is a user-level
> program rather than a special kernel, it speaks 9P2000
> (and not 9P1), and there are numerous other improvements,
> including enormous file names and also soft updates so that
> the disk image is always in a consistent state.

Does this mean we don't need il protocol anymore?

Kenji

Re: [9fans] 4th edition file server available

[Skip Tavakkolian]

> there are numerous other improvements,
> including enormous file names
> g% x=`{perl -e 'print "a"x2000'}
> g% >$x
> g% ls -l $x

This is a new challenge to people coming up with class names (and depth)
for Java.

[9fans] 4th edition file server available

[Russ Cox]

The new 4th edition file server, named Fossil,
is now available on sources.  There are some
how-to docs for setting up Venti and Fossil at:

http://plan9.bell-labs.com/wiki/plan9/setting_up_venti
http://plan9.bell-labs.com/wiki/plan9/setting_up_fossil

The man pages fossil(4) and fossilcons(8) are
the definitive reference.  /sys/doc/fossil.pdf (aka
http://plan9.bell-labs.com/sys/doc/fossil.pdf)
describes the disk structures and also the Vac
structures for those interested in hacking the
internals.

Conceptually, Fossil is similar to the current file server
with Venti instead of a WORM juke box, but practically
there are many other differences.  It is a user-level
program rather than a special kernel, it speaks 9P2000
(and not 9P1), and there are numerous other improvements,
including enormous file names and also soft updates so that
the disk image is always in a consistent state.

It is still a work in progress, but it's ready to be used
by those feeling adventurous.

Enjoy.
Sean, Jim, Russ


g% x=`{perl -e 'print "a"x2000'}
g% >$x
g% ls -l $x
--rw-rw-r-- M 8 rsc rsc 0 Jan  8 01:30 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
g%