Chris Muller
2014-03-29 21:32:51 UTC
Levente is right, we need to get the new website set up under a
webteam id, that only has access to what it needs for the website.
Chris C., yourself, and Timothy (if he wants), and I'm interested too,
added as group members.
This would take care of the immediate security need, as well as
distribute some of the burden currently concentrated on Chris C.
Chris C., is this something you would like to handle or would you
prefer someone else do it?
proxies cache them forever.
I wanted to use a separate subdomain (or a set of subdomains) for the
static files, but it's easier for now to use a path prefix with the
/static/*/...
Where * is the version label - a sequence of alphanumeric characters, and
... is the actual path to the resource. For example for /img/foo.jpg the
actual path is
/static/v1/img/foo.jpg
If there's a new version of the resource with the same name, then all you
have to do is to replace v1 with v2, then v3, etc.
If you upload the static files to the server, then I'll configure nginx to
serve them.
More than a week has passed since my mail, so I decided to fetch the files
myself. I extracted the names of the static files from the source code, and
downloaded them to the server to the /var/www/www.squeak.org directory. I've
configured nginx to serve these files as I described before. Please check if
all of them are there.
The next step is to change the source code in the image to use these files.
I saw that the css and js files are not minified, so that's another thing to
do. I also think that the source code of the web site should be versionned
by MC, and probably stored on source.squeak.org to let others modify it.
The image serving the www.squeak.org site is constantly using ~50% CPU for
some reason (even when it's not serving any requests). It's also being ran
by root, which is really bad from security POV. Please fix these.
Levente
webteam id, that only has access to what it needs for the website.
Chris C., yourself, and Timothy (if he wants), and I'm interested too,
added as group members.
This would take care of the immediate security need, as well as
distribute some of the burden currently concentrated on Chris C.
Chris C., is this something you would like to handle or would you
prefer someone else do it?
locator at: (ALPath / 'favicon.ico')
put: (ALFileResource on: (FSLocator imageDirectory /
'squeakfavicon.ico') resolve)
This code is in the current squeak.org image for the favicon, which is a
file in the imageDirectory. The simplest thing is for Altitude to be fed a
path to wherever Levente wants to put the files for the homepage. The files
currently served from my webpage could then be dropped into that directory.
'Loading Image...
'].
html footer: [ html img src: (ALPath / 'poweredbysqueak.png') ].
That is if the image will handle it's own files. If we are separating
static and dynamic requests in nginx for speed and such, then I think I
html footer: [ html img src: '/img/foo.jpg' ].
FSReference * 'img' / 'foo.jpg')
where nginx sees the token /img/ and sends the request to wherever the
static files are served from.
The goal is to let nginx serve the static files, and let the browsers andput: (ALFileResource on: (FSLocator imageDirectory /
'squeakfavicon.ico') resolve)
This code is in the current squeak.org image for the favicon, which is a
file in the imageDirectory. The simplest thing is for Altitude to be fed a
path to wherever Levente wants to put the files for the homepage. The files
currently served from my webpage could then be dropped into that directory.
'Loading Image...
html footer: [ html img src: (ALPath / 'poweredbysqueak.png') ].
That is if the image will handle it's own files. If we are separating
static and dynamic requests in nginx for speed and such, then I think I
html footer: [ html img src: '/img/foo.jpg' ].
FSReference * 'img' / 'foo.jpg')
where nginx sees the token /img/ and sends the request to wherever the
static files are served from.
proxies cache them forever.
I wanted to use a separate subdomain (or a set of subdomains) for the
static files, but it's easier for now to use a path prefix with the
/static/*/...
Where * is the version label - a sequence of alphanumeric characters, and
... is the actual path to the resource. For example for /img/foo.jpg the
actual path is
/static/v1/img/foo.jpg
If there's a new version of the resource with the same name, then all you
have to do is to replace v1 with v2, then v3, etc.
If you upload the static files to the server, then I'll configure nginx to
serve them.
myself. I extracted the names of the static files from the source code, and
downloaded them to the server to the /var/www/www.squeak.org directory. I've
configured nginx to serve these files as I described before. Please check if
all of them are there.
The next step is to change the source code in the image to use these files.
I saw that the css and js files are not minified, so that's another thing to
do. I also think that the source code of the web site should be versionned
by MC, and probably stored on source.squeak.org to let others modify it.
The image serving the www.squeak.org site is constantly using ~50% CPU for
some reason (even when it's not serving any requests). It's also being ran
by root, which is really bad from security POV. Please fix these.
Levente
Levente
Chris