COSI Linux Build

COSI Linux Build
Contact Person:	Benjamin Lannon
Last Update:	Fall 2015
Services:	Linux Image for COSI

Introduction

This page summarizes how to set up and maintain the COSI Linux Build.

The lab build was once a separate project from the ITL Linux Build, but to reduce maintenance work, the ITL build is now the primary effort, and it serves well enough as the COSI lab build once several minor adjustments are made. The script /root/cosify.sh is stored in the ITL image, which can be run as root to prepare the image for use in COSI as opposed to the ITL. This script is maintained along with the ITL image itself.

The ITL image is currently running on the latest testing version of Debian Stretch

Project Members

Current Maintainer

• Benjamin Lannon

Past Maintainers

• Graham Northup
• Alan Beadle
• Corey Richardson
• Chris Peterman
• Michael McKenna-Mattiaccio
• Tim Kopp
• Mark Platek

Software Requests

Requests for software for in COSI can go below, but please add requests for software in the ITL on the ITL Linux page. Software that belongs in COSI but not in the ITL can be installed by the "cosify.sh" script.

Software needed to be added to a img

• Neovim
• Vivaldi

Needed additions to cosify.sh

These things should be added to the cosify script. At the moment they must be done manually.

• Reformat swap partition as swap so that it will be swap again (not sure why this is a problem, but it is)
• Modify /etc/fstab
• Replace eth1 with eth0 in /etc/network/interfaces

Initial Configuration

Installation

Clone the stock ITL image with clonezilla, install other software, and whatever other changes are in that script at the moment. Presently, this includes:

• Allowing the "sudo" group to bypass password authentication.
• Adding "csguest" to "sudo".
• Changing the root password to the COSI build standard. (Warning: This password is visible to anyone who can read the file; thus, the file is intentionally rwx only to root.)

Note that adding a user to a group does not affect existing sessions; this is a long-standing Linux (and probably *NIX) behavior (in that groups for users are only generated on login). This will cause issues with "sudo" for the logged-in csguest session, assuming it is from there that the script is run for the first time. You may want to use either "su" to root or "su csguest" to log in again with the new group memberships. The problem will be fixed on the next login.