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
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
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
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
port 6192 after creating the SSH tunnel per Levente's advice.
port 6912, not 6192.
Hey Levente, something I meant to ask you -- you mentioned its possible if one presses Cmd+. [dot] that it could possibly interrupt the RFB server process -- if that happens, then I guess its over for viewing that image then, and would require restarting the image, is that right?
Hi Chris,
Thanks for doing this!
On Mon, Aug 29, 2016 at 03:00:38PM -0500, 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/
Looks good to me. I can connect to the web interface, and I can also connect with Monticello to the trunk repository at http://box4.squeak.org:9092/trunk.
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.
Good, this is a chance to fix those wierd file ownerships. The original user ID for squeaksource on box2 apparently had a UID that just coincidentally matched the UID for my davidlewis account on box4. So when source.squeak.org later got moved to box4, the file ownerships appeared to be "davidlewis", when they should have been owned by the user ID for squeaksource. An unintended side affect was that people assumed that "davidlewis" had something to do with setting up source.squeak.org (really I did not).
Dave
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
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
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@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
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
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.
He has?! I had no idea..
The newer VMs are built by Travis and Appveyor
I DID know that..
and are hosted on Bintray[1]. I think 5.1
was released with the last versions there[2].
Okay, thanks for the heads-up, I don't follow the VM development.
I only saw the HT VM in there, Eliot are you still producing the non-HT vm's? I use HT everywhere I can, but for cases where one cannot get root access, will non-HT vm be available?
Hi Chris,
If you click the download button [1] you get a list of all vms that Travis/AppVeyor built including non-ht vms. Hope this helps.
Fabio
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm#the-cog-vm-source-tree
Squeak 5.1 was released with the OpenSmalltalkVM 201608171728 which is Cog moved to GitHub and which was built on 17th Aug 2016. You can find the Linux VM at http://files.squeak.org/base/Squeak-5.1/vm-linux.zip
Fabio
box-admins@lists.squeakfoundation.org
-
Chris Muller -
Chris Muller -
David T. Lewis -
Fabio Niephaus -
Levente Uzonyi