[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-hackers-public] New VMs status update

From: Bob Proulx
Subject: [Savannah-hackers-public] New VMs status update
Date: Sun, 31 Jul 2016 17:01:36 -0600
User-agent: Mutt/1.5.24 (2015-08-30)

Savannah Hackers,

A few weeks ago Ruben released internal0 to us as a production ready
VM system.  Yay!  The first new system!

This is a conversion from the previous Debian system to the now FSF
preferred Trisquel system.  Currently internal0 is a Xen system for
the reason of the host it is running upon.  When the new FSF system is
set up it will get migrated to be a KVM system.  This mostly affects
device names but also has an effect with getty and the system console.
We do not have access to the system console on the new VMs yet.
Saying all of this to say that nothing is in the final form.  But
good enough for the moment.  Better than before.

I have configured internal0 and documented the process here:

I have cloned what is now a copy of the production internal database
onto the new internal0 system for testing.  Since the previous
internal was the least trouble of any of the previous VMs it makes
sense that it was the easiest to migrate and the least trouble.
Things went easy with internal0.  It was only a few learnings
concerning differences between Debian and Trisquel.

At this moment the database is not in live use.  (Assaf and I have
been using it in development mode on the new frontend0.)  That hasn't
been the most urgent need.  Hopefully switching over from internal to
internal0 will be as simple as updating the database data on the new
internal0 and then switching frontend, vcs, download to accessing the
new database IP address.  Then stopping the old database on the old
system to catching anything we missed.  (Things are never as simple as
they should be however.)

Is this a good week to do this?  I would like to do this Monday or
Tuesday depending upon what is happening then.  I want to do this
during the day when we are available to jump on any problems that we
cause that we don't know about now.

We have available to use for development a small frontend0 and a small
mgt0 system.  These are available to us for software development but
not scaled up for production.  The key requirement of all three of
these systems is that they don't require much disk space and therefore
we can get them.  The FSF tell me they don't have the disk resources
to provide us with a full vcs0 or download0 clone.  We continue to
wait for those.

On frontend0 Assaf and I have been tag-teaming working on getting
the host system configured and getting Savane running.  Again all is
documented on SavannahHosts page referenced above.  Whereas the
internal0 documentation is fairly complete the frontend0 documentation
is still the same work in progress as is the turn-on of Savane there.
In the end most of the work will be described in the version control
logs as changes to savane are committed.

That it is up and running to this point is a testament to how much
work Assaf has put into making it work there.  Thanks Assaf!  There
are obviously a few more problems to work through with the biggest one
staring us in the face with the menu.txt file that is messing up the
navigation on the left side.  Don't expect to be able to log in unless
you override your local /etc/hosts table to call it
or the site rejects the wrong named cookies.  The name is also the
reason for the certificate error.

Now that we have newer software available it makes the Let's Encrypt
certificates via Certbot quite trivial.  Except for the problematic
Apache configuration that we currently have to work around.  I plan on
replacing the current certificates with Certbot ones.  That will allow
us to use the additional URLs while we are in development.

I think we should plan on converting from MySQL to MariaDB as time
goes by.  I think we should plan on converting from the current MyIASM
engine db tables over to the ACID3 correct InnoDB engine.  Sometime in
the near future now that we can.

I put in another request for vcs0 and download0.  But to fit within
the small disk space available I asked for a small system.  I am told
that they can provide a small system.  I really want to start working
on the new sshd authentication process.  I plan on allowing NFS from
the current vcs and download to the new small vcs0 and small download0
systems.  That will allow us to keep making forward progress there.

Additionally I have a request in for an RFC1918 private LAN IP address
allocation for use in infrastructure communication.  Use it for the
persistent connectivity between hosts.  For example the internal
database vm has no need of a public facing IP address.  Use the public
IP address for a floating address so that services such as the web
frontend can be switched between hosts by moving the floating IP
address.  That would also provide us with some future capability for
fail over and perhaps load balancing.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]