Louis, we agreed that one area is sufficient.
We (Martin, Michael) will use different subdirectories for their 
specific content.

We would like to know
- what path has to be used for upload via scp?
- will subdirectories (eg. helpcontent, apidoc) be created 
automagicly via upload?
- what URL has to be used for download?
- will remove and list of files/directories also be possible?

Thanks

Shall we create create separate issues for providing ssh keys with 
should be allowed for upload?

the path is /home/upload
I believe you can automatically create subdirectories using scp -r, but I'll get 
that data for you too.
-adding MT and assigning this issue to Taska. 
-louis

Hi,
I conferred with Andrewr and he believes it would be faster and 
easier to use the sf1.mirror.openoffice.org for this purpose. 
Evidently, to use the website server actually requires fairly 
unique scripting, which would take time and resources.

my sense is that you could use sander's key for the sf1 mirror 
and scp -r files into, say, /api/files/foo immediately. These files 
will be mirrored by ny1, and will be downloadable by the public, 
should they learn of them. That is the drawback. 
but only you will be able to upload.
The rsync by volunteer mirrors shoudl be just limited, too, to 
those directories they are rsyncing to.
-louis

Assigning to Stefan to find out his view on this.

I have no problem with public access to those directories.
I have concerns regarding introducing new content at sf1/ny1 in the
phase before 1.0 is out.
We would have to create either a subdirectory builds/ with
builds/641c, builds/641d, ... to avoid administration efforts at mirrors.
That means correcting many URLs.
Or if new directories (help content, apidoc, ...) are at the same
level as 641c, 641d, ... a mirror would have to reflect each new
directory in it's configuration - not only once but ongoing.Another
possible solution could be the creation of a directory misc which
could be excluded by mirrors.
Martin, Michael, about what amount of data are we talking?
helpcontent X MB
apidoc X MB

helpcontent is about 200 MBytes

apidoc: about 16 MB
udkdoc (Java+C++): 16 MB (will probably double soon)

I would like to move forward with
miscellaneous/helpcontent
miscellaneous/apidoc
miscellaneous/udkdoc
Martin will ask Sander for the key.

This question is still open:
- will removal of files/directories also be possible?

Reassign issue to owner of selected subcomponent

filed issue with collabnet (9296) to create directory "miscellaneous"
and move the existing "helpcontent" there.
other directories can be created via scp -r.
-louis

This is a "top 5" issue, but it's assigned to no-one.  I'm assigning
this to Louis as he updated it last.

Hi, we've been debating this issue and now it's time to take it out of
the debate team and get it moved on.
Assigning to Kat (support).
Kat, the issue relates to granting MH certificate.
Stefan has provided more context in a letter he sent to core; let me
kow if you want me to incorporate that here.
best
louis

Ops has created the miscelaneous directory on sf1, the other
requirements for this directory are being evaluated internally.

Internal discussions continue. I will update on further developments. 

Internal discussions continue to scope out the solution.

The issue is still in process internally.

There is no further news on this issue at this time. I will update
when there is something significant to report or at least weekly if
there are no objections.

Making progress. Martin's key has been installed and there is
agreement on access and management of the directory. The same method
used to remove other files on sf1 would continue to be used, with more
complex requests directed to operations via IZ.
The point of exclusion from mirroring to ny1 as mentioned in your
mail, Stefan, remains open. 		

Nothing has been concluded onthe mirroring to ny1.

It has been concluded that the miscellaneous directory will not be
excluded from mirroring to ny1. 
This may be discussed further with the EM (David) if desired.

removing from top5 and closing

For technical reasons we have to move the issue to another subcomponent tan 'www'.
Sorry for bothering you with this generated notification message. There is no
need for any action from yor side.
Thanks for your understanding, Stefan