What we use:
The Linux installation supported by the CS Lab is based on a Fedora
distribution, with local customizations and additions.
Fedora is a community-supported open source project, sponsored by RedHat.
Some of the key components of our systems include:
- Kerberos for password authentication,
- NFS for home and project directories (made available via
an automouter),
- SAMBA for file service to Windows machines,
- SSL-enabled imapd and pop3 mail servers, and
- secure logins via ssh or Kerberos.
- OpenJDK for our Java offering.
- LibreOffice for our office productivity product.
Distribution strategy:
Although Fedora is our starting point, we do not support a pure
'vendor' distribution. We install all the mandatory core and base
packages, but selectively choose among the various optional packages. We
build our own kernel and may replace or add several packages to suit our
environment and facilitate support.
Beginning in the summer of 2011, we migrated our supported OS to
a 64–bit Intel platform. Our
kernel is customized to include support for a standard set of hardware
found on our workstations and servers. Consequently we do not support all
the hardware configurations that might work on a pure Fedora
installation. This customization provides for a leaner kernel that is
much easier to maintain. Any researcher thinking of buying a system to run
CS Lab-supported Linux should have the configuration reviewed before any
orders are placed, to ensure that the hardware ordered will be supportable
by the Lab.
There are minimum hardware requirements that must be met in order to run
CS Lab Linux. The requirements may change from year to year. Old hardware
cannot be accommodated indefinitely. Disk space requirements typically
grow with each new OS release. Memory requirements also tend to grow over
time. So we re-evaluate what constitutes an acceptable minimum hardware
configuration when we adopt a new OS release. The minimum hardware
requirement rarely affects new purchases and generally applies only to the
forced retirement of older (usually truly ancient) machines.
To the extent possible, we run the same set of software on all Lab managed
Linux machines to which users have access. There are some exceptions, of
course. Some software is licensed for specific systems and some server or
desktop oriented software may not be needed on all systems. Also, the
instructional machines generally contain additional packages, e.g.,
special programming languages, needed for various courses.
Use of third-party licensed software is limited and not actively
encouraged. Such software is usually harder to support and it doesn't
always continue to work when we upgrade to new versions of the base OS.
The CS Lab Linux is only available to run locally. Although we mostly use
open source software, some of the software is specially licensed or
contains trademark-ed components. We do have redistribution rights for
all the software that we use.
On Lab supported Linux systems, root privileges are only granted to CS Lab
staff personnel. This is true for both desktop systems and for project
machines purchased for research.
Update strategy:
We typically install new OS versions of Linux once per year during
the summer, although exceptions may occur. For instance, we deferred
upgrading Linux during the summer of 2003, due to time constraints
imposed by the departmental move from Sieg to the Allen Center.
In creating our local Linux distribution we adopt the latest release of
the 'vendor' distribution that is available at the time we begin building
and testing our new release. Our upgrades do not track each vendor
release one for one. Fedora generally distributes two or
three releases a year, while we only do one. Our work on a new release
usually starts in late spring, even though it is end of summer to early
fall before all systems are running the new OS.
With a new OS release comes updated versions of most packages.
This generally includes newer versions of the kernel, compilers,
libraries, editors, browsers, image viewers, and other software
components. Users should expect some changes.
Hopefully most changes are for the better, but occasionally upgrades
introduce incompatibilities to which users must adapt. It should also
be noted that the vendor software set is not static. The vendor
sometimes drops packages that were previously available and often new
packages are added to the distribution.
For Lab managed Linux machines, an OS upgrade really means a fresh
install. We often call them upgrades, since we're moving from an older
base OS to a newer one, but in practice we perform a new installation.
That is, we repartition if necessary, remake the system filesystems, and
install fresh copies of all software packages. Old packages are thus
effectively purged. For desktop machines with a local /scratch partition,
we make best effort to leave the contents of /scratch intact at OS upgrade
time, if no repartitioning is necessary. However, the contents of
/scratch are never guaranteed. For research cycle servers, /scratch is
never maintained across an OS upgrade.
With a new OS version comes a new /uns area for research Linux systems.
This practice was adopted many years ago, per request by the research /uns
maintainers. Due to the large number of research Linux systems, upgrades
necessarily take place over several weeks, sometimes running to months.
Having a fresh /uns area targeted to the specific OS release reduces
software incompatibilities that might otherwise be introduced during the
transition. The older /uns eventually goes away as the number of systems
running the older OS dwindles.
On the instructional side there are fewer Linux systems and the upgrade
time is much less drawn out. Since there is less time with machines in
transition, the instructional Linux /uns area is retained across OS
upgrades.
We typically make at least one system with the new installation available
for testing by the research community before we begin mass upgrades.
This is our 'beta test' platform. Its purpose is to allow users to
experience and experiment with the new software base. Useful but
unsupported packages, in particular the /uns area, should be recompiled so
that those packages are known to be compatible with the new base
installation. The beta-test period is also the time to make any needed
adjustment in scripts or configurations in order to work with the new
software versions. Beta is the time we especially welcome feedback so
that we can hopefully iron out any major problems before the full-scale
release. After mass distribution it is harder to make adjustments.
How we do maintenance:
Software maintenance is an on-going process. We depend on the base
software distributor for most updates. We apply all vendor updates that
are appropriate for our systems. For components that we customize, add,
or replace, we watch for security alerts and patch accordingly. Since we
update immediately as required we expect all Lab managed Linux machines to
be up on the network at all times. Systems should generally not be
powered off for any length of time without making special arrangements
with support. Systems that are down for prolonged periods may miss
important security updates and hence may require a fresh installation
before they can be reconnected to the network.
Although security updates take priority, we also install any appropriate
bugfix or enhancement updates made available by the base software
distributor. In addition, special instructional courseware packages may
be either added or upgraded on a quarterly basis. We update, as needed,
any package that is an important part of the CS infrastructure. We may
also occasionally upgrade a package if the new version contains important
bug fixes. But for the most part, security issues aside, we do not track
version changes to individual packages outside of the upgrade cycle.
Likewise, we rarely introduce a new package mid OS cycle.
Bleeding edge software packages and the frenzy of continually updating to
the latest and greatest verions we leave to the maintainers of /uns.
|
CSE Home 
