Black and White - courses.cs.ut.ee€¦ · 9/28 System Administration. 2012. markko.merzin@ut.ee...

transcript

1/28System Administration. 2012. markko.merzin@ut.ee

System Administration

Software

http://courses.cs.ut.ee/2012/syshald/

Outline

● Ownership and usage rights● Installing● Updating● Software library

Software

software – the binding component

storage processorbuses/data paths

Software: ownership, usage rights

● ownership of the copy– all the (owners) rights for the copy

transferred to the end user– copyright may remain with the publisher

● license to use the copy– client is licensed to use the copy of the

software, but ownership of the copy remains with the publisher

Free Software

● end user owns the copy● owning the copy ≠ owning the copyright

– owner's rights and liabilities– accepting the license grants additional rights,

user will be bounded by the terms of license

Free Software License types

● Copyleft– aim to preserve freedom of the software

● GNU General Public License

● Permissive– aim to give more freedom to the users

● BSD License, Apache License

Proprietary software

● proprietary – „closed“, „commercial“– end user does not own the copy– end user is granted the right to use the copy– accepting the license is prerequisite of using

the software– no standards, vendors impose their own rules

Software: Cost

● freeware● voluntary donations● free for personal use● shareware● try & buy, trial● for charge

Source Openness

● closed source – only vendor/publisher and their partners can access the code

● shared source – user gains access to the code by signing agreement, ownership remains with vendor

● open source – code accessible by everyone, end-user owns the copy

– access to source does not automatically imply the rights to modify the source

Counting the Users

● license tied to one workstation - per-seat● tied to one user - per-user● installed to many locations, allowed to use N

copies concurrently - concurrent, floating● license covers whole department/company or

faculty/campus – site-licence, campus licence

● license tied to particular hardware – OEM

License Duration

● forever● annual fee (rent)● software support/maintenance/assurance

Physical Tokens

● also known as dongles– a piece of hardware that enables the use of

some software application– usually an USB or device– sometimes used with license servers

License server

● Keeps track of floating / concurrent licenses ● Upon starting, application performs a

checkout of the license● When the application is closed, a check-in is

performed● No more free licenses to check out?

– application does not start,

– ..or starts for a limited period of time..

– ..or starts with a limited functionality

Installing Software

● only install what you own or are licensed to use

● temporary and trial installations– must be clearly distinguished– must not be used to do “real work”

● software install rights– person with install rights must understand the

concepts of software licensing

Packaging

● managing large quantities of software installations will get complicated

● this can be mitigated by software packages

Concepts for packages and package management

● Dependency handling● Recommendations● Consistency (do not break anything)● Configuration (restoration)● Distribution● Upgrade avoidance

Evolution of Packaging

● source code (or binary code) with half-automated install

– tarball (incl Makefile), .jar

● install packages (incl removal functions, basic dependencies)

– .exe install packages in Windows

Evolution of Packaging (2)

● standard package formats with tools to manage them (removal, audit, dependencies, single package manager)

– RedHat Package Management (rpm), Debian Package Format (deb), Solaris Package (pkg), Windows Installer (msi)

● software repository systems (dependency resolving, central updates, single toolset)

– APT, Yum, YAST2/Zypp, CPAN, PEAR

Software Repository

● set of published software (available over Internet)

● has structure, meta-info● compatible with some software

management application

Software Repository (2)

● complex aspects of dependency, version, update management are kept hidden from the end user

● one system can be connected to many repositories, single tool for management

Repository Examples

● install repository for the OS● drivers from hardware vendors

– nVidia, ATI, Intel graphics card drivers

● applications from third-party– Packman, rpmforge, EPEL, Blastwave

● for-charge and proprietary software– NightStar LX, Eucalyptus

● repository for SW development libraries– CPAN, PEAR, CRAN

Software Updates

● Upgrade versions are usually cheaper than full versions

– Functionality updates

● Security updates – should be free● Bug fixes – usually free● Software “lifetime” – for how long is the

software version supported?

Software Updates (2)

● Security updates– Security updates must be (semi)automated!

– Ideal model: ● 1. Security update gets published● 2. Adminstrators test the update – in

(semi)automated way● 3. If the update passes testing, it will be

delivered to all the systems needing the update via automated infrastructure

Software Updates (3)

● version updates (upgrades)– major upgrades need planning– too quick upgrades will have a negative

impact– learn from the experience of other companies

● if possible, the upgrade should be simultaneous over the company

– new and old version may not be fully compatible

Why software updates are so common nowadays? Why software vendors do not “get it right” at the first attempt?

License Store

● repository of license tokens (agreements, license files, ..)

● with every token, list of existing installations is kept

● each new installation should begin with registering itself in the license store

Software Library

● ITIL: Definitive Software Library● structured library of software:

– installation packages of licensed software– different versions (for testing, in use, archive)– “install keys” can be either kept in software

library or license store

Questions?

Black and White - courses.cs.ut.ee€¦ · 9/28 System Administration. 2012. markko.merzin@ut.ee...

Documents