I intend to upgrade the VM on box4 VM.r2776 (Aug. 2013) to VM.r2987 (June 2014). The intention here is to refine the install/removal process. I just did this on my Debian Wheezy box, so it seems pretty straightforward.
Installing:
- get a Cog binary from mirandabanda.org
- use Ken's cogdeb.zip to make a deb
- install with dpkg (i.e. dpkg -i cogvm_2776-1_i386.deb)
- execute "man squeak" to see if it's loaded
Removing:
- check the package name with dpkg-query -l
- see it's actually called "coglinux" as opposed to cogvm or squeak
- dpkg -r coglinux
So, as I said, I just did this on my server and is seemed to work OK. I plan to upgrade the VM from last year's model (2776) to this year's (2987). If there's anything people with more LInux experience could add to this process, I'd be happy to hear it.
Chris
I've added /etc/security/limits.d/squeak.conf as per the instructions
for a Cog Spur at
http://www.mirandabanda.org/files/Cog/VM/VM.r3006/README.3006 (It's
necessary because Cog Spur is _only_ a heartbeat VM on Linux.)
Simply adding the file is insufficient. Usually one needs to log out &
log back in for the security changes to take effect. In Jenkins' case,
that's a restart of the service.
I've just done that, but it seems to not have been sufficient. I'll dig further.
frank
We have an objective to get the squeak.org services moved from the old box2 infrastructure
to the new box4 (and box3) servers provided by the SFC. I raised this as a topic at the
Squeak board meeting last week, partly because the recent outage of source.squeak.org and
other services is a reminder that we need to make some progress on this front.
I made one point to the board, and I want to repeat it clearly here: I am talking about
moving our existing squeak.org services from one server to another. We need to
accomplish this independently of new development, such as Chris Cunnington's work on
a new SqueakMap server. So to use that as an example, we need to get the old SqueakMap
service moved from box2 to box4. Development of the new SqueakMap should proceed in
parallel with that, but it should not prevent us from moving the old SqueakMap service
at the earliest possible opportunity (Chris C, sorry to use this as an example, you
just happen to be the person doing active new development, so I am using this to illustrate
the point).
Chris Muller offered to move the old SqueakMap from box2 to box4, and I offered to
provide whatever interpreter VM may be need to run the old image. If no objections,
I will go ahead and install the same VM that is currently installed on box3, and
Chris Muller can follow up on the SqueakMap move.
Levente, does this make sense to you? And if so, is it reasonable for Chris Muller and
me to move a single service such as SqueakMap, as opposed to moving a larger number
of services all at once? I'm afraid I am not very knowledgeable about setting up Apache
configurations, so I do not really know how easily this can be done. But if we could get
the old SqueakMap service moved, it might be a good start.
And of course, once the old SqueakMap server is running on the newer box4 infrastructure,
it should be that much easier to update to Chris Cunnington's new service when the time
is right.
Thanks,
Dave
I have installed the same interpreter VM box4 as currently used on box3. This
VM is currently running the squeaksource.com image on box3, and should be suitable
for running squeakmap images or any other existing image that cannot currently
run on a Cog VM.
I am following Ken Causey's guidelines for system administration, so the locally
built Debian package files are saved in /root/localdebs. Administrator notes are
in /root/admin-log.txt, which is maintained in RCS version control in the archive
file /root/RCS/admin-log.txt,v.
Chris Muller, this VM should be suitable for running a headless squeakmap image
on box4, using the /usr/local/bin/squeak script to run the VM.
Dave