Closed yogev1978 closed 9 years ago
Is the latest build stable?
I like the idea, I think there are 2 possible ways to do this:
I like the latter idea. It saves my server some traffic and doesn't make the project dependable on cronjobs.
Since those are all night-build versions, they are unstable by definition. But the last release version we have is Kolibri 0.7.7.0 from December 2009 which is not a good idea either. Try this one - it should work fine: http://builds.kolibrios.org/eng/history/svn5318-img.7z
The reason I suggested this idea is so that very lazy users (such lazy they don't even want to install any emulator or boot KolibriOS from USB stick) are still able to check latest versions of KolibriOS without having to do anything else besides opening a new browser window.
Regarding your 2 suggested ways, I am not sure our sysadmin will like the 2nd idea, but I will check with him and get back to you. To be honest, I thought you can just link to the image file on our website without any "cross-origin" setup.
Most static websites should have CORS enabled. I never heard of any web sites DDOS'ing other sites over CORS. Besides, the Referer header will still be sent, you can easily see how much traffic is caused by CORS traffic.
Any updates on this @yogev1978 ?
@yogev1978 @ysangkok I've enabled CORS. Please recheck and update if something goes wrong.
@XVilka
If the headers were set correctly, and v86 was modified to support 7z compression, this link would boot KolibriOS: http://copy.sh/v86/?profile=custom&fda.url=http://builds.kolibrios.org/eng/history/svn5318-img.7z (DON'T USE THIS LINK, IT DOESN'T WORK, SEE COMMENT BELOW)
Since CORS prevents it from loading now, the compression issue isn't relevant yet.
Chrome shows the following error in the console: XMLHttpRequest cannot load http://builds.kolibrios.org/eng/history/svn5318-img.7z. Request header field Range is not allowed by Access-Control-Allow-Headers.
On my server, I am using the following Apache directives, and it works:
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "Range"
Header add Access-Control-Expose-Headers "Content-Range"
Header add Access-Control-Allow-Methods "GET"
You are missing Allow-Headers and Expose-Headers.
Would it be possible to host the images and compress them using HTTP's built-in DEFLATE encoding? This would make it possible to load them into v86 after modifying it to support responses that don't support byte-ranges. Alternatively, they could be hosted uncompressed, this would make them work in v86 right away, as soon as the CORS issue is fixed.
@copy @ysangkok XVilka is KolibriOS server owner and administrator. I have directed him to this issue, and asked his opinion regarding enabling CORS on our server. He did not have any objection, so he will take it from here.
I've added missing headers but this link still can't boot KolibriOS...
@XVilka Of course not, there is still the compression issue. As I said, if the images were stored uncompressed, it would work.
If you execute this, it would work: for i in *.7z; do 7z x $i -so > $i.uncompressed; done
Alternatively, there could be a script doing it on-demand.
@ysangkok oh, sorry, we'll add uncompressed images too, bit later. Thx for the help!
Thank you for responding so quickly :)
This is the link to the latest uncompressed image - you should use it instead: http://copy.sh/v86/?profile=custom&fda.url=http://builds.kolibrios.org/eng/data/data/kolibri.img The link you originally used was not good anyway because it points to a specific image, and we want the website to always download the latest image, which is located at the link I provided.
Oh, I didn't even know you had a link like that set up. If people don't need old versions, I guess we don't to decompress the old ones at all then. I guess this issue is solved?
@ysangkok Our users do need old versions, that's why we have them stored in backup folder on our server (in compressed form). But we want http://copy.sh/v86/?profile=kolibrios to always present the latest version, which is available (in uncompressed form) via this link: http://builds.kolibrios.org/eng/data/data/kolibri.img . Only if this link doesn't respond because of a server problem on our side, please use the backup image that you have stored on http://copy.sh/v86 website.
But right now http://copy.sh/v86/?profile=kolibrios still presents the stored image, so it has first to be modified to http://copy.sh/v86/?profile=custom&fda.url=http://builds.kolibrios.org/eng/data/data/kolibri.img and then this issue can be closed of course.
Yup, I'll make your image available at http://copy.sh/v86/?profile=kolibrios
Thanks for the help everyone. If you need anything, let me know.
This is only a suggestion (enhancement). For example, in KolibriOS we have an auto-build script that produces a new OS image every time a commit is made to our SVN. Your copy of KolibriOS image is half-year old already - we have fixed and changed a few things since then.
So instead of getting a new image manually once in a while (every few months?), maybe you can update it automatically whenever it's created? Or even better, instead of hosting the image locally on your server, just link to latest image on our server, so that each time a user starts KolibriOS VM, it would be always started with latest version.
Or you can try to load the image from our server as a primary option, and revert to using locally stored image as a fallback option in case our server is not available...