====== Software Installation & Maintenance ====== ---- * See the section of [[cs_471_-_general_sysadmin_principles#software_installationmanagement_system_maintenance|General Admin Principles]] that deals with software and system maintenance. * Software can be evil. * Can open doors to system intrusion through exploitable weaknesses in software, network ports needed by the software. * Can results in system instability, performance degradation, loss of disk space. * User demand requires software to be installed. * But the administrator should avoid installing software, as far as it is possible. ===== Package management systems ===== ==== Packaged pre-compiled binaries ==== === RPM - Red Hat Package Manager format === * widely used * used on rockhopper, since its a Fedora Linux system * To install a RPM package rpm -i package.rpm * To upgrade a RPM package rpm -U package.rpm * To uninstall a RPM package rpm -e package.rpm * To query all RPM packages currently installed rpm -qa * RPM does not resolve package dependencies by itself * Tools to resolve RPM dependencies * yum (Red Hat, Fedora), up2date (Red Hat Network), autoupdate === Dpkg (DEB) - Debian's binary package format === * [[cs471/cs_471_-_introduction_unix_installation#installing_debian_linux_packages | See previous description]] * widely used * Many popular, third party applications (firefox, google-chrome) are available now in both RPM and DEB format. === BSD package management === * FreeBSD [[https://en.wikipedia.org/wiki/FreeBSD_Ports|ports]] system * automatically download/compile/install from source * NetBSD tgz packages * pkgsrc system * Mac OS X * [[https://en.wikipedia.org/wiki/Fink|fink]] * [[https://en.wikipedia.org/wiki/MacPorts|macports]] * [[https://en.wikipedia.org/wiki/Homebrew_(package_management_software)|homebrew]] * Gentoo Linux * Uses a BSD ports-like system ---- ==== Scripting language-specific module management ==== * Scripting languages have had their own module management systems for a while. * Perl modules can be installed [[https://www.linuxcloudvps.com/blog/how-to-install-perl-modules-using-cpan-on-linux/|via CPAN]]. * Python modules can be installed using [[https://packaging.python.org/discussions/pip-vs-easy-install/|easy_install or pip]]. * Ruby modules can be installed using [[https://en.wikipedia.org/wiki/RubyGems|RubyGems]]. * Normal users can use these systems without admin intervention, at the cost of possibly using more disk space per user and causing version conflicts. ===== Advantage of (most) package management systems ===== * conflicts between packages are supposed to be resolved * package maintainers work with each other and the package maintainer community to resolve file naming conflicts * official Red Hat RPM repository * official Debian deb repository * assures quality control and conflict resolution ---- ===== Doing it yourself from the source code ===== * The GNU [[https://en.wikipedia.org/wiki/GNU_Build_System|build system]] (autoconf/automake) * Software installs from source can often be reduced to a simple series of commands * the '''./configure; make; make install''' routine * usually installs to the '''/usr/local''' directory tree * Newer [[https://en.wikipedia.org/wiki/List_of_build_automation_software#Build_script_generation_tools|alternatives]] to the GNU build system exist * Any type of scripted configuration/compilation system is preferable to having to deal with raw Makefiles or hand-editing the source code. * Source-installed software sandboxing systems * sandboxing: each program exists only in its own separate subdirectory (and only one subdirectory) * [[https://www.gnu.org/software/stow/|GNU stow]] * user-controlled sandboxing * BSD/Gentoo ports, pkgsrc, fink, macports, homebrew system may also use sandboxing systems of their own. ---- ===== Making software available ===== * making executables available * Add new //bin// directories to global $PATH in /etc/profile * making libraries available (Linux) * Add new lib directories to /etc/ld.so.conf & run ldconfig (Linux) * Add new lib directories to LD_LIBRARY_PATH in /etc/profile (old) * Other environment variables that need to be globally set * MANPATH, CLASSPATH (Java) ---- ===== Commercial software ===== * Licenses * Ethical issues * Buy single user license and use for a whole class * Legal? Ethical? * License daemons * Run in background to ensure that license is not violated * enforce per user licenses * enforce connection limits to an OS or service ---- ===== Maintaining a lab or a large group of machines ===== * Making sure all machines have same software and same versions of software and get upgraded/patched at the same time * //cssh// and similar solutions have their uses but can require a lot of screen real estate * They have an advantage that you can see what's going on on each machine. * Mostly suited to labs and clusters in which the machines use the same OS on the same or similar hardware. * simple shell script that visits each machine via ssh and runs a job in the background as root * a "push" solution * requires every machine to be up and running, else miss an update (as with //cssh//-like solutions) * wake-on-lan can take care of machines that are powered off * but can't help machines that are locked up/crashed * a scheduled update script run via cron that downloads and runs an update script at bootup or nightly * a "pull" solution * much more sophisticated and flexible "[[cs_471_-_configuration_management|configuration management systems]]" * "imaging" software, exemplified by software such as Norton Ghost, in which a group of machines are made to be in sync with a "golden image" (a machine on which a desired and set system configuration and software are installed). * good for lab environments on which you want to return all lab machines to a desired state after a day of student usage * also good for major system upgrades ---- ===== Upgrading software ===== * How should upgrades be performed? * Questions that should be considered: * When is it appropriate to upgrade software? * Is the upgrade needed now or can it wait? * How critical is the upgrade? * Is there a maintenance window? * How long will the upgrade take? * Has the upgrade been sufficiently tested? * Is there a backout path in case the upgrade causes problems or goes wrong? * Is there a reliable backup of the system? * Also see Software section of [[cs_471_-_general_sysadmin_principles#software_installationmanagement_system_maintenance|System Administration Principles]]. ---- ===== Lab Activity ===== ==== Software packages: Google Chrome ==== Install the Google Chrome web browser on your virtual Linux systems. * Record the details of the installation in your admin journals. * Download the appropriate package from http://www.google.com/chrome. * Note the software license that is used by Google Chrome. Also, see the EULA and fine print. * Is there an open-source alternative to or version of Google Chrome? * Where does Google Chrome install itself? * Can this information be found in the package file you downloaded? * Note also the software repository changes that the Google Chrome installation made. ==== Software packages: Rootkit Hunter ==== Install Rootkit Hunter on your virtual Linux systems. * Record the details of the installation in your admin journals. * Download the source code from http://rkhunter.sourceforge.net to a Downloads directory. * You can use the following wget command: * '''wget https://sourceforge.net/projects/rkhunter/files/latest/download?source=files -O rkhunter-1.4.6.tar.gz''' * Extract the source code from the downloaded archive and note the software license used. * Run //rkhunter//. * An older version of Rootkit Hunter is available for installation via //apt-get// on your Linux VMs. In the case of this software package, why might downloading and running from the source code preferable? ==== Software packages: drjava and bluej ==== Install the //drjava// and //bluej// java IDEs on your virtual Linux systems. * Download the most recent packages from http://drjava.org and http://bluej.org. (Link to [[http://rockhopper.monmouth.edu/~jchung/download/drjava-beta-20160913-225446.jar|drjava jar file]]) * Neither of these software packages is available for download using //apt-get//. * See the Linux lab machines on which both //drjava// and //bluej// are installed. * Record the details of the installation in your admin journals. ==== Software packages: puppet & puppet master ==== Install the ''puppet'' and ''puppetmaster'' packages on your virtual Linux systems (VMs). Install just the ''puppet'' package on your Linux containers. ----