ch 1
ch 1
ch 1
(ITec4112 )
University of Gondar
Faculty of Informatics
Department of Information Technology
December 10, 2024
Gondar, Ethiopia
1
Objective of the Course
Manage a network
Create and manage users and groups;
Manage disks and files;
Backup and restore system and user data
Remotely administer a network
Use widows and linux server to manage
remote computer and pheripheral device
2
Self-test objectives
1. What kinds of issues does system and network
administration cover?
2. Is system and network administration management or
engineering
3. Why does the physical environment play a role in system
and network administration?
4. Is system and network administration a science? Why/why
not?
5. State the top-most principles that guide network and
system administrators
3
Unit One
Introduction
What is network and system administration?
Network and system administration is a branch of
engineering.
It concerns the operational management of human–
computer systems.
It is unusual as an engineering discipline
System and network administration addresses both the
technology of computer systems and the users of the
technology on an equal basis.
4
Cont’d…
Network and system administration is about putting together a
network of computers (workstations, PCs and supercomputers).
A system administrator works for users, so that they can use the
system to produce work.
However, a system administrator should not just cater for one
or two selfish needs, but also work for the benefit of a whole
community.
It is often a difficult balancing act to determine the best policy,
which accounts for the different needs of everyone with a stake
in a system.
It’s about hardware, software, user support, diagnosis, repair
and prevention.
5
Cont’d…
System administrators need to know a bit of everything:
The skills are technical, administrative and socio-
psychological.
The terms network administration and system
administration exist separately and are used both variously
and inconsistently by industry and by academics.
System administration is the term used traditionally by
mainframe and Unix engineers to describe the management of
computers whether they are coupled by a network or not.
To this community, network administration means the
management of network infrastructure devices (routers and
switches).
6
The Challenges of System Administration
System administration is not just about installing
operating systems.
It is about planning and designing an efficient
community of computers so that real users will be able to
get their jobs done. That means:
Designing a network which is logical and efficient.
Deploying large numbers of machines which can be
easily upgraded later.
Deciding what services are needed.
Planning and implementing adequate security.
Providing a comfortable environment for users.
7
Cont’d…
Developing ways of fixing errors and problems which
occur.
Keeping track of and understanding how to use the
enormous amount of knowledge which increases every
year.
Some system administrators are responsible for both the
hardware of the network and the computers which it
connects
i.e. the cables as well as the computers.
8
Cont’d…
On the other hand, an understanding of how data flow from
machine to machine is essential as well as an understanding
of how each machine affects every other.
In all countries outside the United States, there are issues of
internationalization, or tailoring the input/output hardware
and software to local language.
Internationalization support in computing involves three
issues:
Choice of keyboard:
e.g. British, German, Norwegian, Thai etc.
Fonts: Roman, Cyrillic, Greek, Persian etc.
Translation of program text messages.
9
Bugs and emergent phenomena
Operating systems and programs are full of bugs and
emergent features that were not planned or designed for
learning to tolerate bugs is a matter of survival for system
administrators; one has to be creative and work around these
bugs. They may come from:
Poor quality control in software or procedures.
Problems in operating systems and their subsystems.
Unfortunate clashes between incompatible software,
i.e. one software package interferes with the
operation of another.
Inexplicable phenomena, cosmic rays, viruses and other
attacks.
10
The meta principles of system administration
Many of the principles in this context derive from a single
overriding issue:
They address the predictability of a system.
The term system clearly implies an operation that is
systematic, or predictable
However, unlike simple mechanical systems, like say a clock,
computers interact with humans in a complex cycle of
feedback, where uncertainty can enter at many levels.
The above reason makes human–computer systems difficult to
predict, unless we somehow fix the boundaries of what is
allowed, as a matter of policy.
11
Principle 1 (Policy is the foundation)
System administration begins with a policy
– a decision about what we want and what should be, in
relation to what we can afford.
Policy speaks of what we wish to accomplish with the
system, and what we are willing to tolerate of behavior
within it.
It must refer to both the component parts and to the
environment with which the system interacts.
If we cannot secure predictability, then we cannot expect
long-term conformance with a policy.
12
Principle 2 (Predictability)
The highest level aim in system administration is to work
towards a predictable system.
Predictability has limits.
It is the basis of reliability, hence trust and therefore
security.
Policy and predictability are intertwined.
What makes system administration difficult is that it
involves a kind of ‘search’ problem.
It is the hunt for a stable region in the landscape of all
policies
i.e. those policies that can lead to stable and predictable
behavior.
13
Cont’d…
In choosing policy, one might easily promote a regime of
cascading failure, of increasing unpredictability, that degenerates
into chaos.
Avoiding these regimes is what makes system administration
difficult.
As networks of computers and people grow, their interactions
become increasingly complex and they become non-deterministic
i.e. not predictable in terms of any manageable number of
variables.
We therefore face another challenge that is posed by inevitable
growth:
14
Principle 3 (Scalability)
Scalable systems are those that grow in accordance with policy
i.e. they continue to function predictably, even as they increase in
size.
The important point to understand about predictability is that it
has limits.
Human–computer systems are too complex and have too many
interactions and dependencies to be deterministic.
When we speak of predictability, it must always be within a
margin of error.
If this were not the case, system administration would not be
difficult.
15
Philosophy of System Administration
The species of being a system administrator may change from
platform to platform, there are underlying themes that do not.
Although the following themes make up the philosophy of
system administration.
Automate everything
Document everything
Communicate as much as possible
Know your resources
Know your users
Know your business
Security cannot be an afterthought
Plan ahead
Expect the unexpected
16
Automate Everything
Most system administrators are outnumbered either by
their users, their systems, or both.
In many cases, automation is the only way to keep up.
In general, anything done more than once should be
looked at as a possible candidate for automation.
some commonly automated tasks:
Free disk space checking and reporting Backups
System performance data collection
User account maintenance (creation, deletion, etc.)
17
Cont’d…
Business-specific functions :-
Pushing new data to a Web server
Running monthly/quarterly/yearly reports, etc.
Also the functions automated by system administrators are only
limited by an admin's willingness to write the necessary scripts.
In this case, being lazy (and making the
computer do more of the mundane work) is
actually a good thing.
Automation also gives your users the extra benefit of greater
predictability and consistency of service.
18
Document Everything
If given the choice between installing a brand-new
server and writing a procedural document on
performing system backups, the average system
administrator would install the new server every
time.
While this is not at all unusual, you must document
what you do.
Many system administrators put off doing the
necessary documentation for a variety of reasons:
"I will get around to it later.“
Unfortunately, this is usually not true. Even if a
system administrator is not kidding themselves,
the nature of the job is such that everyday tasks
are usually too chaotic to "do it later."
19
Cont’d…
Even worse, the longer it is put off, the more that is
forgotten, leading to a much less detailed (and
therefore, less useful) document.
"Why write it up? I will remember it."
Unless you are one of those rare individuals with a
photographic memory, no, you will not remember
it.
Or worse, you will remember only half of it, not
realizing that you are missing the whole story.
This leads to wasted time either trying to relearn
what you had forgotten or fixing what you had
broken due to your incomplete understanding of
the situation.
20
Cont’d…
In addition many system administrators will put off
doing the necessary documentation for a variety of
reasons.
Project plans
Server logs
Diagrams (such as system flowcharts, logical and
physical network diagrams, and so on)
Backup and restore process
Feature and equipment requests
While this is not at all unusual, the fact is that you must
document what you do.
21
Communicate as Much as Possible
When we come to your users, you can never communicate
too much.
Be aware that small system changes you might think are
practically unnoticeable could very well completely
confuse the administrative assistant in Human Resources.
In general, it is best to follow this some what-paraphrased
approach used in writing newspaper stories:
1. Tell your users what you are going to do
2. Tell your users what you are doing
3. Tell your users what you have done
22
1. Tell Your Users What You Are
Going to Do
Make sure you give your users sufficient
warning before you do anything.
The actual amount of warning necessary
varies according to the type of change
(upgrading an operating system demands
more lead time than changing the default
color of the system login screen), as well as
the nature of your user community (more
technically adept users may be able to
handle changes more readily than users
with minimal technical skills.)
23
Cont’d…
At a minimum, you should describe:
The nature of the change
When it will take place
Why it is happening
Approximately how long it should take
The impact (if any) that the users can
expect due to the change
Contact information should they have any
questions or concerns
24
2.Tell Your Users What You Are Doing
This step is primarily a last-minute warning
of the impending change; as such, it should
be a brief repeat of the first message,
though with the impending nature of the
change made more apparent ("The system
upgrade will take place TONIGHT.").
This is also a good place to publicly answer
any questions you may have received as a
result of the first message.
Continuing our hypothetical example, here
is one possible last-minute warning:
25
3.Tell Your Users What You Have Done
After you have finished making the changes, you
must tell your users what you have done.
Again, this should be a summary of the previous
messages (invariably someone will not have
read them.)
However, there is one important addition you
must make. It is vital that you give your users
the current status.
Did the upgrade not go as smoothly as planned?
Was the new storage server only able to serve
the systems in Engineering, and not in Finance?
These types of issues must be addressed here.
26
Cont’d…
Of course, if the current status differs from what you
communicated previously, you should make this point
clear and describe what will be done (if anything) to
arrive at the final solution.
In our hypothetical situation, the downtime had some
problems.
The new CPU module did not work; a call to the system's
manufacturer revealed that a special version of the
module is required for in-the-field upgrades.
On the plus side, the migration of the database to the
RAID volume went well (even though it took a bit longer
than planned due to the problems with the CPU module.
Here is one possible announcement:
System Downtime Complete
27
Know Your Resources
System administration is mostly a matter of balancing
available resources against the people and programs
that use those resources.
Some of the resources are ones that seem pretty
obvious:
System resources, such as available processing power,
memory, and disk space
Network bandwidth
Available money from the IT budget
But some may not be so obvious:
28
Cont’d…
Time (often of critical importance when the time involves
things such as the amount of time during which system
backups may take place)
Knowledge, whether it is stored in books, system
documentation, or the brain of a person that has worked at
the company for the past twenty years
The important thing to note is that it is highly valuable to
take a complete inventory of those resources that are
available to you, and to keep it current .
Alack of "situational awareness" when it comes to
available resources can often be worse than no awareness.
29
Know Your Users
Although some people bristle at the term "users" (perhaps due to
some system administrators' use of the term in a derogatory
manner)
Users are simply people that use the systems and resources for
which you are responsible.
As such, they are central to your ability to successfully administer
your systems; without understanding your users, how can you
understand the system resources they will require?
For example, consider a bank teller. A bank teller will use a
strictly-denid set of applications
Two entirely different users with two entirely different needs.
Make sure you learn as much about your users as you can.
30
Know Your Business
31
Cont’d…
Applications that must be run within certain time
frames, such as at the end of a month, quarter, or year
the times during which system maintenance may be
done.
New technologies that could be used to resolve long-
standing business problems
By taking into account your organization's business, you
will and that your day-to-day decisions will be better for
your users. And for you.
32
Security Cannot be an Afterthought
No matter what you might think about the
environment in which your systems are running, you
cannot take security for granted.
Even standalone systems not connected to the Internet
may be at risk (although obviously the risks will be
different from a system that is more connected to the
outside world).
Therefore, it is extremely important to consider the
security implications of everything that you do.
33
Cont’d…
The following lists illustrates the different kinds of
issues that you should consider:
The nature of possible threats to each of the
systems under your care
The location, type, and value of data on those
systems
The type and frequency of authorized access to the
systems (and their data)
34
Cont’d…
While you are thinking about security, do not make the
mistake of assuming that possible intruders will only
attack your systems from outside of your company.
Many times the perpetrator is someone within the
company. So the next time you walk around the office,
look at the people around you and ask yourself this
question:
What would happen if that person were to attempt to
subvert our security?
35
Plan Ahead
A system administrator that took all the previous
advice to heart and did their best to follow it would be
a fantastic system administrator.
Eventually, the environment will change, and one day
our fantastic administrator would be caught at-footed.
The reason? Our fantastic administrator failed to plan
ahead.
Certainly no one can predict the future with 100%
accuracy.
However, with a bit of awareness it is easy to read the
signs of many changes:
36
Cont’d…
An offhand mention of a new project gearing up
during that boring weekly staff meeting is a sure sign
that you will likely need to support new users.
Talk of an impending acquisition means:-
You may end up being responsible for new (and
possibly incompatible) systems in one or more remote
locations
Being able to read these signs (and to effectively
respond to them) will make life easier for you and your
users.
37
Expect the Unexpected