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. Then I can change the absolute references to my site to the disk from:
html footer: [ html img src: 'http://www.chriscunnington.com/poweredsqueak.png'].
to something like:
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 need to change the links to something in Altitude like:
html footer: [ html img src: '/img/foo.jpg' ].
with a locator like:
locator at: (ALPath / 'img' / 'foo.jpg') put: (ALFileResource on: FSReference * 'img' / 'foo.jpg')
where nginx sees the token /img/ and sends the request to wherever the static files are served from.
Chris
http://box4.squeak.org:9971/seaside/ss
Here's a beta to replace map.squeak.org. Not all of the features work (Join, New Proejct, Save in the Your Project form). I didn't see much point in doing everything until qmail is installed on box4.
It's Seaside2.8 and SS2. (Well, I've removed Magritte and re-installed SSTableReport, so perhaps I'm hacking SS2Retro). I'll save SS2Retro to its own repo. I'll then push SMServer to the SqueakServices repo.
Chris
cc'd to box-admins, as there's some overlap
squeak.org issues list:
- zip resources for faster download
- use minified versions of files
- get that 404 image (broken paper showing a code browser) out of my email Archive and install
- check multi platform layouts (i.e. cell phone, tablet)
- doesn’t work on IE8
- sometimes hogs the CPU, needs to be watched
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?
On Fri, Mar 28, 2014 at 10:50 PM, Levente Uzonyi <leves(a)elte.hu> wrote:
> On Thu, 20 Mar 2014, Levente Uzonyi wrote:
>
>> On Thu, 20 Mar 2014, Chris Cunnington wrote:
>>
>>> 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.
>>> Then I can change the absolute references to my site to the disk from:
>>>
>>> html footer: [ html img src:
>>> 'http://www.chriscunnington.com/poweredsqueak.png'].
>>>
>>> to something like:
>>>
>>> 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
>>> need to change the links to something in Altitude like:
>>>
>>> html footer: [ html img src: '/img/foo.jpg' ].
>>>
>>> with a locator like:
>>>
>>> locator at: (ALPath / 'img' / 'foo.jpg') put: (ALFileResource on:
>>> 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 and
>> 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
>> following pattern:
>>
>> /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
>
>>
>>
>> Levente
>>
>>>
>>>
>>> Chris
>>>
>>>
>>
>
I killed the Altitude process on box3, as the homepage is launched on box4. I figure it's just eating cycles that could be better spent on Jenkins and SqueakSource.
Chris
It's not ideal to serve squeak.org's resources files from my website forever, so how do we serve files from box4?
I'm going to post this idea and leave it for a week before I change anything.
I figure a week is enough time for people to look at the question.
nginx serves files from /usr/share/nginx/.
It's default is /usr/share/nginx/html.
The basic directive looks like this:
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
I'm thinking we have directories for each service in the default directory:
/usr/share/nginx/ftp
/usr/share/nginx/map
/usr/share/nginx/source
/usr/share/nginx/wiki
/usr/share/nginx/www
/usr/share/nginx/lists
We could add a new subdomain called "files" and serve from it.
http://files.squeak.org/maphttp://files.squeak.org/ftphttp://files.squeak.org/sourcehttp://files.squeak.org/wikihttp://files.squeak.org/wwwhttp://files.squeak.org/lists
Thanks,
Chris
I went into box2 and killed the old homepage image. You can see the line that was the process here [1].
This also involved deleting the symlink as well. [2] The service directory in /home/website is now gone as well.
The wildcard DNS routes unknown subdomain requests to some daemontools service for looking at old mailing lists. I don't think it's a process.
It's some kind of cgi-bin thing. Check it out:
http://foobar.squeak.org
Deleting symlinks and service directories is a tad barbaric. I'm getting under svc -d /service/fooservice and such to stop services instead.
But this is a sunset box. By St. Patrick's Day next year, it will be gone.
Chris
[1]
website 577 24.9 10.2 1051420 99212 ? S Mar16 44:39 /usr/bin/squeakvm -vm-display=none /home/website/website/squeaksite.image
[2]
/service
lrwxrwxrwx 1 root root 24 Sep 27 2008 www.squeak.org -> /home/website/servicenew
>I have taken the liberty to tinker with the dns stuff:
>I changed the dns data file to:
> * make box2 explicit
> * point A for 'squeak.org' and 'www.squeak.org' to box4
> * point MX for 'squeak.org' to 'box2.squeakfoundation.org'
> * point * to box2
>As soon as the caches update, everything should be fine again™
These changes look great.
Thanks, Tobias!
Chris