• SystemAdministration
• Systems
• Test

• To Systems Overview - To Software Software - To Software-Assessment - Software/Assessment

Systems - OLD Testserver

First of all, the current testsystem (as of 2019) is described in Software/Assessment/testserver.

Basics

The mission of the test system is to provide a platform for software patches to be tried and tested. Once tried and tested, Software Assessment team reviews them and passes them to (critical) online system.

Our production test server machine has been newly deployed in early 2010 and moved over to the IT-SLS.de testserver (see below)

• Software-Assessment central entry point for documentations

• Software Testers portal (entry point) with addtl. infos of patches applied for testing

Testing

To test, use it like the main site. First, *create a new test account* because this system doesn't have access to your account on the main system. Then, log in and test the feature of the day.

Do not use your real password for this test account and especially do not use your standard "Security Questions", because many people have access to this database and can look up the security questions and their answers!

WARNING: This server does not have a copy of the CAcert user database, and has a lot of incorrect/spurious data in its database as a result of several kinds of tests.

Discussions on what needs to be tested happen .. where?

Who can create CAcert certificates for this machine? Currently it uses a certificate from my company's internal CA since I could not find the one who has registered cacert.at... BernhardFröhlich 2010-11-13

Administration of Testing systems

Test systems are managed and controlled by SoftwareAssessmentTeam. They provide the systems administrators for administrating it.

• TestSite/ConfigurationDetails has the configuration parameters used for this test site

• TestSite/LoggingIn has the instructions for logging in via ssh

• TestSite is another page that has been used to document testing. Which is more current?

There are three sorts of users:

• sysadms, who have ssh root access and maintain it.
  • These people are generally part of infrastructure team.
• developers, who have ssh access and upload patches.
  • Access to developer shell account is lightweight: isAnAssurer, isADeveloper, hasAPatch. Use common sense in allocation.
  • developers should investigate the Test Image (VMWare) below and install it on their local machine for faster development time
• testers, who access via the https links above.
  • can be any CAcert member in principle?

Technical Specifications

Each test System is made of:

• two IP#s

  • server-cert	test1.cacert...	the HTTP main webserver and password login over HTTPS
    client-cert	secure.test1.cacert...	client certificate access requires a separate IP# from the main password login site

• access to a physical tty so ioctls work? (not necessarily with a cable in it)

Specs on Sonance.net VMs

Test1

• Admins: Jandd, Ted
  • perhaps PG, Evaldo

• emergency crowbarring: Matthias G foo at s.n, or if desperate: subik yellow at s.n or Iang at iang.org.

• IP#s:
  • 193.238.157.83 (eth0) server-cert
  • 193.238.157.84 (unassigned) client-cert
  • the last two are unassigned, just configure as usual (eth1, eth2).
• 512Gb Ram; 10GB disk

"Physical"

• VM hosted on Xen 2.6.18

• hosted by Sonance.net on one of their VM systems, write their support@ or their sonance-tech@lists... for help

• host is located in Funkfeuer.at who respond to hosting@

• debian-5 "etch" is standard install (can be apt-upgraded to 6 or 7 apparently)

"Scooter"

• Admins: Mario, Iang

• emergency crowbarring: Matthias G foo at s.n, or if desperate: subik yellow at s.n or Iang at iang.org.

• IP#s:
  • 193.238.157.85 (eth0)
• 512Gb Ram; 10GB disk

Test Image (VMWare) how to build your own

Moved to http://wiki.cacert.org/wiki/SystemAdministration/Systems/Development

Test Image hosted at SLS

Operating system was set up by Wytze according to the current live web db machine. Source code comes from an repository, which holds a copy of the source code taken from the tarball. It is intended to continuously import every new tarball into the repository to enable developers to work more conveniently. The whole process of development, testing and release is WIP and will be posted shortly.

See instructions written for test1 above, the basic testing process is the same. There will be an wiki page which holds additional information on the status of the machine (which patch is to be tested, who is responsible for this test cycle, testers and results). URL of the entry page will be posted soon.

Historical

EvaldoGardenali ran test1 in US of A until that machine's retirement in 2008.

• CategorySystems

• CategorySoftware

• CategorySoftwareAssessment