[Box-Admins] Re: request support to finish upgrade of source.squeak.org

Wed Aug 31 21:21:48 UTC 2016

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 at 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.
>>>
>>>    http://box4.squeak.org:9092/
>>>
>>> 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 at 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
>>>>>>
>>>
>>
>