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

[Chris Muller]

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.

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
>>>>>
>>
>