Proceedings of 2nd International Conference on Information Technology Based Higher Education and Training, Kumamoto, Japan July 4-6, 2001
Real Life Scenarios in the Class: Topics on Computer System Administration Eduardo Jacob, Mariví Higuero, Alejandro Muñoz Faculty of Engineering Bilbao – Department of Electronics and Telecommunications University of the Basque Country
[email protected],
[email protected],
[email protected] Abstract This paper shows authors' experience with students that learn how to administer a computer system during other subject classes or laboratories. Although in our School this is not a topic by itself, students usually find themselves installing, configuring and administering computer systems to fulfil other tasks. This is fine for them because it is an added value (they will not normally make a life from system administration), but nevertheless we find that the environment where they work is too ideal. As there is a trend to try to recreate real life scenarios in the class we have been thinking about how to transform this environment to maximize the experience. Our objective is to take advantage of this circumstance and by adding some additional requirements to the work of the students and getting the responsibles of the courses involved, get a better understanding of system administration. In this paper we intend to show these ideas and how to implement a more real and useful scenario for our students and for their future employers.
1. Introduction It is quite a common thing for us, as professionals on teaching, to face business partners who bring about some critics on educational topics: teaching topics that are not useful, a technological gap between lessons and reality, not teaching about techniques/products that are state of the art... Finally, even we are sometimes told that our students need to be fully taught again to become skilled. Even if those statements clearly reflect some aspects of the teaching/learning process that seem to be missed by their authors, they certainly carry some truth since, after all, they come from some of our final clients. The authors of this paper are teaching topics on Operating Systems, Operating Systems Programming, Servers & Services and Advanced Network Services at the
School of Engineering (University of the Basque Country). In some of our courses we let students manage servers they need to setup in order to accomplish their work. For example: a Linux Server with Apache, MySQL and Sendmail, to develop an Information server, or an NT Server along with Jonah software to test a Public Key Infrastructure architecture. So, although in our School this is not a compulsory topic by itself (in the sense that every student must not take this course), students are often required to install, configure and administer computer systems to fulfil other tasks. This is positive for them, as it offers an added value but, however, we find that the environment where they work is still too ideal and we feel that once faced such a need, we should try to improve their learning process and follow a real production environment. We have spent some time thinking over the problem and we would like to share our thoughts, the solutions we are considering and some conclusions on this matter.
2. The problem Sometimes the systems that students will manage on their future jobs are very similar to those they use at our Faculty. We find that Unix-family systems are clearly and perfectly represented by Linux or FreeBSD on a PC platform (we can even try other systems as Solaris for X86). However, in our particular case, we find ourselves not using many Microsoft NT © or Windows 2000 ©, servers because the price of the software to be used over the operating system itself is very expensive when dealing with specialised applications. Anyway, we find the concept much more important than the tool used to fix it. See [1].
2.1. System Administration Duties First of all, we must try to define which are the tasks of a System Administrator. In the most extensive case these could be the tasks a system administrator should perform:
•
Designing and planning system configuration: choice of computers, operating systems, connectivity and software must be accurately done.
•
Adding and removing hardware: from printers to complex devices. Upgrading if necessary the Operating System.
•
Managing users accounts: this duty consists on adding new users accounts and removing the dead or expired accounts. Operating Systems usually offer tools for the automation of these tasks. But even with these tools, the administrator has to take care of other aspects like temporarily storing disposed files before definitely erasing them.
•
•
Filesystem and process monitoring: there are several activities that must be performed almost every day like handling and analysing log files, making sure services like email or news are working right, and testing the availability of system resources such as disk space. This also includes checking for suspect activity that could indicate a system penetration. New software installation: sometimes, software upgrades are to be done and many times it implies downtime. System administrator should plan them and notify users of the timing and estimated downtime. They should also develop procedures in order to restore the previous state in case the upgrade does not work as expected.
•
Troubleshooting: when there are system problems, administrator must analyse, diagnose and finally try to fix them.
•
Maintaining System Documentation: system administrator must document all the system information. For example, there should be a system manual concerning all the design aspects and physical specifications. If new software or hardware equipment is installed, it must be written down in the system manual. It is a good habit for system administrators to have a problem report notebook to keep information about problems and this may find the cause of these problems and the adequate solution that should also be stored in a solving problem report. This way, when the administrator is replaced, the new one could have all this information available. There must be also documented information containing users and administrator emergency procedures in case of
catastrophic situations. It is advisable to have an agenda with backup status, dates, locations… •
Security policies: this task has increasing relevance nowadays. Systems in open environments or directly exposed to the Internet are subject of attacks. System administrators should implement security procedures that include monitoring of security lists, installation of security patches and eliminating not needed services.
2.2. Environment Analyzing the condition in which our students manage systems, we can conclude that is far away from the real situation they will find in a production environment. Some of the reasons and consequences of the environment differences are now detailed. 2.2.1 Customers pressure. Students do not work under the pressure of giving services to customers so, for them, it is not a problem if system goes out of service. As a result there are some important administrative tasks they omit because of “this lack of responsibility”: •
There is no need for making backups, as the usual rule is that users are responsible for their own data. They do not plan or even think about it.
•
When students have a problem they just do not hesitate in shutting down the server because they find it to be the fastest and better solution. Thus there is no work or analysis done to reach the origin of problems that could help to reproduce them or even help to make the changes to solve it without rebooting.
•
Since there is no problem analysis no frequent problem reports are developed either and students are not used to solve those problems in a systematic way.
•
Students do never have to face up to system upgrades without lost of service so they are not used to develop procedures for these kinds of situations.
2.2.2. Small-scale time. The short period of time in which students are in charge of the system administration is not enough for them to go through the usual “maintenance problems” that they will find in a production environment. This fact takes out some consequences: •
Log
files
with
no
size-limit
growing
up
enormously and filling all the disk free space. They will never confront to a stacked system because of no more free space left. •
Server parameters customisation using the feedback of the hardware equipments monitoring.
•
Snapshot and database files growing too enormous because of wrong transactions or other reason. Students never plan a resize procedure for database.
•
There are hardware maintenance procedures, cleaning filters or checking bad blocks lists can make the system get down if it is periodically performed. Students will never enough time to “suffer” those problems.
like that not stay
2.2.3. Small-scale size. The systems that students manage are small-scaled and isolated. They are usually not part of a network management systems. This has also some conse-quences over the students learning process: •
Students just learn to manage isolated systems like a server but never a whole platform made of powerful computers (active and standby with geographical duplicity), workstations, routers, switches, lines to connect active-standby computers, local workstations, remote workstations, network servers, X-25 line servers…
•
They are not acquainted with problems involving multi-platform systems and they do not learn to administrate it.
3. Proposed Solution The solution we have devised consists on a networking environment in which we use hardware, and software, and in which we install a policy which puts some “pressure” on the whole.
3.1. The networking environment The networking environment in which the proposed solution will be operating needs to be detailed. The network deployment is exclusively managed by the University Services and it includes routing, DNS and cabling. The networking environment is almost 100% IP based, with some islands of Novell IPX/SPX servers. From the point of view of connectivity, the Central Services of the University of the Basque Country close incoming ftp, telnet, and http except for designated servers. These servers must be operated and actively managed by staff. There are also some other common sense filtering rules. Nevertheless we could define it as mainly open from the point of view of access. At the horizontal level we have a shared segment at 10 Mbps with many (perhaps too many) computers on it. We thought about using masquerading, but that would limit the access from inside to outside with masquerade unsupported protocols. Our lab is connected to the University network through a Linux based bridge. See Figure 1.
Internet
2.2.4. Network environment. The network environment is, in terms of security, almost totally open to all kind of attacks. Oddly enough, if they get to correctly manage the system, taking the suitable security measures, they are clearly gaining experience. This is because standard business environments are much closer, restricted and controlled, for there are usually firewalls that keep at large most of the attacks and there are inside security policies that limit the user behaviour. These are some points that they tend to overlook: •
•
They do not close unneeded services. They usually leave servers with all the plethora of services that come preinstalled. They do not install security patches or “waste'' time monitoring buglists or reading about it.
PC Based Bridge
Hub
PC
PC
PC
Central Server (Backups)
Figure1. Networking and Hardware Setup
3.2. Hardware
3.4. External Pressure
Our network lab consists of several personal computers, often more than 20 PCs, which students will use during laboratory courses, on a single Ethernet segment. There is also a network server, that serves as a bridging firewall and can also host several additional services, such as web servers, ftp servers and so on. In order to perform as an effective firewall and service host, it must have a sufficiently fast CPU (at least 500 MHz) and other hardware resources, mainly RAM memory (at least 64MB) and also a second network interface for routing experiments with Zebra software. Hard disk storage is not a relevant factor, unless intrusion detection systems (IDS), which usually generate large logs, are to be installed. In fact, having not a very large disk capacity can also become an advantage, because students will have to perform backups from their machines to the server, so they will also have to worry about how much information they put into the server, as we will mention later. It is very important to take into account that computers should be as similar as possible, in such a way that hardware compatibility, solving installation problems and updating programs processes are much easily performed, or may even be carried out simultaneously over all of them. At this point, we are not trying to develop a laboratory with computers that have centralised resources to get software, configurations and user accounts as in [3]. We are considering the idea of installing ZIP devices on every computer for system administration courses as mentioned in [2], so that students can create their own complete Linux system on a 100MB or 250MB ZIP disk, booting the machine with a boot floppy. That would free the hardware for use by different users.
This point is changing the forgiving environment in another one which is more restrictive. The solution we have devised consists on setting and defining the environment as much tightly as possible in order to generate some pressure. This pressure is exercised by two different means: Configuration requirements and administrative requirements.
3.3. Software So far, we face a little disadvantage: the architecture we propose is shared by different courses being taught at the same laboratory, so we must have Windows operating systems installed in our machines, which are sometimes shut down or rebooted to change current working operating system. We have chosen RedHat Linux 6.2, although we might also consider using FreeBSD in the future, as its centralised distribution schema and support is more similar to other professional operating systems. The choice of this distribution is somewhat due both to its preponderance in our business partners and also for the incident reporting and solving procedures.
3.4.1. Configuration requirements. These requirements are more oriented to technical aspects of system administration. The assessment of these requirements is done through automated tools as vulnerability or port scanners or direct system scrutiny. Really, we use some of the procedures we have devised to ensure that servers which are under our responsibility meet the security requirements for connection to our university network These are some of these requirements: •
Log files should be stored in small partitions, which should imply the use of some kind of log rotating and/or relevant data extracting utilities.
•
List of services that can be used, that means that the default operating system installation must be tweaked.
•
Operating systems must be maintained permanently updated to their last security patches. That means that they should locate security related servers or mailing lists (e.g.: bugtraq) to get information about new vulnerabilities and associated patches. Perhaps in the future we could try to make the system compliant with security evaluation methods as [7].
•
Definition of backup procedures of both configuration data and information. As there are not tapes available for every computer, students will need to do them over a centralized server. Here the definition of the data to be securely kept is more important than the procedure itself.
•
Maintaining a configuration management manual. This manual should reflect the actual system configuration. It should contain the configuration changes made to the original system, including the security patches installed up this moment and the application setup and configuration. The objective of this manual is to reflect the work that must be done to transform a computer in a fully functional and secured server.
3.4.2. Administrative requirements. These requirements should appear in their assignment work. They are related to procedures that a system administrator should setup to assure a service of a given quality. The presence and assessment of these requirements should be checked by the professor of the original subject. This implies sensitivity towards our objectives and us. In our case this it is not a problem as the teachers involved share our interests. These are some of the requirements of this kind: •
Users account managing. Students will have the duty to manage other students accounts and they will have to solve all the problems related with these accounts and answer their requests and complaints. Moreover, accounting manager should advise server’s users about maintenance activities that make necessary shutting down the system.
•
Application mantaining procedures. Students should setup maintenance procedures in order to generate minor effects on users. This imply the planning of downtime and proper dissemination of the schedule.
•
Problems or incidents reporting. Students should establish procedures to efficiently get reports of problem or incidents.
We understand that this additional work is not part of their subject, so we estimate that it should not add much more that a 10% of should not add much We propose to our students some printed bibliography that is available on the net as [4] and also some classics as [5].
4. Conclusions Even if we consider that it is important to get the lowlevel detail, it’s much more important to get a whole perspective of the problem. We would like our students to become more 'system architects' than 'system mechanics' (as stated in [6]) as this is actually more important in their professional life. The solution we have described in this article tries to teach students to administer systems by adding some additional work to other subject’s work. Giving them some requirements that generate some practical tasks and some additional documentation to their final report does this. Some assessment is later needed. This way, our students do not only learn some administering actions that must be performed in a systematic and periodical way during their courses, but they also realize of the relevance of administrator’s duties: they notice how long it takes to keep a good customer
service, in terms of user account management and customer care, and how large is the number of tools they must handle and the information they need to query in order to keep systems up-to-date. Our (at the moment limited) experience shows that students do like the approach. They feel they are gaining a valuable knowledge. The only drawback for them is that they must include more information into their final report and that represents more work. If we evaluate the impact on the professors of the original subjects we can only say that once they see the point and motivation (recreating real conditions) they are willing to include these considerations into the assessment of students’ work. It must be said, that in our network, setting up a server connected to the Internet must be approved and you contract an obligation to maintain your site secure. This is due to a small number of (hopefully) small security incidents caused by poorly administered servers. In spite of the increase of work for students and professors we think that the results are encouraging. This approach makes the time students devote to system administration much more useful for them, even if this makes them “waste” some time. The previous approach of getting fast results on their assignment at the price of overlooking system administration, led to professionals who were not proficient on system administration, even if they had that feeling. Overall, even if the work on the contents of the courses is somewhat reduced, the experience and results are very good.
5. References [1] E. Jacob, J Unzilla, ”Software de dominio público en Educación Técnica Superior ¿una alternativa válida? Experiencias en Ingeniería Telemática”, Proceedings of IV Congreso Iberoamericano de Educación en Ingeniería y Tecnología (INTER - TECH 96), Venezuela, 1996, summary on pp. 73. [2] D. Robert Adams and Carl Erickson, “Teaching System Administration with Linux. Linux in Education”. Linux Journal. February 2001. [3] Juan Antonio Martínez, “Aulas Informáticas en Linux”. Linux Actual. No. 6. May 2000. [4] L. Wirzenius and J. Oja, “The Linux System Administrators' Guide”, 1999, available as “http://www.linuxdoc.org/LDP/ lkmpg/mpg.html.” [5] E. Nemeth and G. Snyder and S. Seebass and T. Hein, ”Unix System Administration Handbook”, Prentice Hall PTR, 2000. [6] David N. Blank-Edelman, “Perl for System Administration”, O'Reilly UK, 2000. [7] Pete Herzog, ”Open-Source Security Testing Methodology Manual. Version 1.5”, 2001, available at “http://www.ideahamster.org/”
