On Wed, 31 Aug 2016, Chris Muller wrote:
3732 is the VM in Eliot's "latest":
http://www.mirandabanda.org/files/Cog/VM/latest/
I think 5.1 was released with 3397, a rather old VM.
You're wrong about both. Eliot has stopped updating that page. The newer VMs are built by Travis and Appveyor and are hosted on Bintray[1]. I think 5.1 was released with the last versions there[2].
Levente
[1] https://bintray.com/opensmalltalk/vm/cog/#files [2] https://bintray.com/opensmalltalk/vm/cog/201608180858#files
On Wed, Aug 31, 2016 at 2:35 PM, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Chris,
I just noticed that the VM is rather old (3732). We should definitely use a newer one. E.g. the one 5.1 was relased with.
Levente
On Mon, 29 Aug 2016, Chris Muller wrote:
Thanks for clarifying the way forward, Dave.
The server is now up and running under daemontools as user "squeaksource" on port 9092, and I can view the image in Remmina on port 6192 after creating the SSH tunnel per Levente's advice.
The only changes I've made to existing production are to the ownership and permissions of its "ss" directory. There is insufficient disk space to make a full copy of the directory, and not really necessary anyway, so I simply soft-linked to it. The group permission was changed from "davidlewis" to "squeaksource" so the new image can write "data.obj" to that directory. I made a backup of the old "data.obj" file, which is more than a year old.
Every start of the image initiates SqueakSource's background recovery process, which ensures all .mcz files are in the SSRepository domain object, saved as "data.obj" and now, also indexed in the "ss.magma" database. Since the Magma DB was initially empty, this background recovery process will continue to run probably for a few days until Magma is fully populated.
I'll be spot monitoring this process until its done -- we're currently at 250M diskspace, 750M of RAM, and 91% CPU.
- Chris
On Fri, Aug 26, 2016 at 9:31 PM, David T. Lewis lewis@mail.msen.com wrote:
That sounds right to me also. Assuming that we have enough disk space (I think there is just barely enough on box4), here are a few other suggestions:
- Keep the current source.squeak.org service running exactly as it is,
with no modifications to the supervise scripts or to anything in the current directory. This service runs on port 9090, with nginx handling the connections to the service on 9090.
- Bring up the new source.squeak.org on its own new port number, say
9092 (SqueakMap is using 9091, so don't use that). Set it up completely in whatever account and home directory we are going to use, and set up the supervise scripts to start the service. This should be a production-ready service in every respect, except that it has not yet been made visible by nginx.
- Run both the old (port 9090) and new (port 9092) services in parallel
for some period of time (maybe a couple of days), until we are comfortable that it runs reliably, does its image backups on schedule, and that it will automatically restart following a server reboot.
- While running in parallel mode, we (and everyone on queak-dev)
can help with testing by connecting to the new service on box4.squeak.org:9092 and making sure that the repositories work properly.
- Depending on how long we run in parallel mode, it may be necessary
to do a final update of "data.obj" before the final switch over to the new service.
- When all is working as expected, do the nginx update to switch
http://source.squeak.org to point to the new service on 9092.
- In the event of problems, the rollback plan is to update nginx
to point back to the original service, which will still be running on port 9090.
- Wait a few days, then shut down the old service on 9090. Take a
good backup, then remove the old repository.
Dave
On Sat, Aug 27, 2016 at 02:16:06AM +0200, Levente Uzonyi wrote:
Hi Chris,
I haven't checked the new zip file yet, but I suggest you set up the image on the server (make sure it has RFB installed). Once it's done, we can create the new nginx configuration on a test subdomain, and if it works well, we can switch over.
Levente
On Fri, 26 Aug 2016, Chris Muller wrote:
Hi all, I've committed the code intended to run our source.squeak.org server to host the repository [http://source.squeak.org/ss], and invited the community to use it to set up their own Personal SqueakSource repositories.
Currently, our production [source.squeak.org] repository is hosted by a stripped "Squeak-3.11-8824" image with lots of notes, workspaces and dirty packages, running on the interpreter VM in the chroot environment. It is not an easy process to extract the SSRepository domain object out of that image and into something the new 5.1 image running under Spur. I did accomplish that, and have the "data.obj" file ready, but if someone else joins [source.squeak.org] before we can deploy it, they'd have to rejoin afterward. Hence, my desire to get the exported data.obj deployed relatively soonish.
However, I really don't feel comfortable attempting to do it on my own without at least getting y'all in the loop so that, in case you would arrive to work to find it down the next morning, you'd know why. :-/
I've created a deployment .zip file and uploaded it to box4.squeak.org:/home/chrismuller/webserver.zip. That zip contains the new 5.1 image ready to be the server running the latest code from the "ss" repository, as well as the converted "data.obj" file (the serialized SSRepository domain object which has all our usernames, etc.). Also included are the scripts whose contents are the commands I would run to do the actual deployment.
The "squeaksource" user under which the server will run is already created. I guess there are just two issues I'm still not sure about:
- the nginx configuration changes needed, if any.
- the automated emails. The email address is in the SSRepository
object, but I'm not sure if any special configurations are needed.
Any advice or support toward completing this would be greatly appreciated.
Best, Chris