| apr96.tar |
Questions & Answers
Bjorn Satdeva The next major system administration related conference, the 5th UNIX System Administration, Networking & Security Conference (SANS) will take place in Washington, DC, May 12th to 18th. In my opinion, this conference and the LISA conference are the major system administration events of the year. The SANS conference has actually become four different programs combined into a single event, as it covers system administration, network administration, security, and new this year, WWW development and management. Also, this year, the tutorials at SANS have been expanded to 22 tutorials spread out over 5 days. I think SANS and LISA offer some of the best tutorials around because, unlike with more commercial offerings, the teachers are people who offer experience they have gathered from working in these areas every day. This gives a different perspective of the topics covered, compared to that of a professional teacher who may never have worked in the system administration trenches. The teachers include luminaries such as Matt Bishop, Michele Crabb, Dan Geer, Rob Kolstad, Evi Nemeth, Marcus Ranum, and Gene Spafford Besides the tutorials, there is a 3-day conference with invited and refereed papers, that often provide solutions that the attendees can apply immediately when they get back to work. For more information, contact the SANS conference office at: Phone: 719-599-4303 FAX: 719-599-4395 Email sans@clark.net: WWW: http://www.usenix.org/events/sans96.html. Tool of the Month One of the biggest problems for many system administrators is keeping track of outstanding tasks. Working as a system administrator almost always means working in an environment in which interruption is the rule. It can be difficult not only to ensure that all reported problems get addressed, but also that users are kept up to date of progress on their specific problems. This month's tool, req, can help you do just that. req is an email-based request tracking system, developed at Northeastern University. This Software implements a system where people with problems or questions can send requests via email to the system administration group responsible for dealing with those issues. Those requests can then be tracked and managed in various ways. You can get req from:
ftp://ftp.sysadmin.com/pub/admin/tracking/req
If you want to check out its predecessor, request, it can be found at:
ftp://ftp.sysadmin.com/pub/admin/tracking/request
For completeness, there is a third tool, gnats, from the GNU project. It was originally developed as a defect tracking system, and according to the GNU folks, it can be also used as a system administration task tracking tool. I have tried it, and have found it quite cumbersome to use, mostly because it is difficult to get a good overview of outstanding tasks. However, it too is available from the system administration source archive at:
ftp://ftp.sysadmin.com/pub/admin/tracking/gnats
An X11 front end to gnats can be found at:
ftp://ftp.sysadmin.com/pub/admin/tracking/gnats
Now to this month's questions:
This must be an issue for many people, or perhaps they just live with the interruptions. Any help would be very much appreciated.
In a more generic sense, it is always important that the system administrator maintain a distance to the problems that require a solution. I know it is often very, very hard to remember that the task is to drain the sump, when you are wading up to your knees in alligators, but unless you are to take the more distant view, it is not likely you will be able to solve the problem in a sustainable manner. As a consultant, I often see clients so bogged down in the specifics of the problem they are attempting to solve that they are unable get the bigger picture. Often I end up helping the client define the high level concept of what they are attempting to do. Now, after that lecture, I'll get off my high horse and try to help with the direct question. I do not know of any publicly available package may be able to do what you want. You may have to look at a commercial package. There are commercial packages that implement printer management, à la mainframe, that may be able to provide you with the necessary solution.
A packet filter implements a strategy whereby each packet arriving at the firewall is examined, and the router or host that is running the packet filter will decide, on a packet by packet basis, whether the packet should be routed toward its destination or should be dropped. Legacy packet filters have some severe shortcomings, because it is necessary to poke big holes in the filter in order to allow very desirable services, such as ftp, through the packet filter. Modern packet filters, such as Sun Microsytems' SunScreen and CheckPoints Firewall-1 use what are commonly called dynamic packet filters, in which the filter rules are rewritten on the fly. A proxy on the other hand makes this decision in the context of the connections. There are two different strategies used to implement a proxy, circuit level proxies and application level proxies. The circuit level proxy is in some respect similar to a packet filter, as it will determine up front whether the connection should be allowed or denied. Because this decision is made at the beginning of the connection, the circuit level proxy will often be able to provide a better feedback in its logging than a packet filter. (An example of a circuit level proxy is the publicly available packet SOCKS (written by Dave Koblas), which is utilized in some commercial firewalls, such as IBM's NetSP, and in a redesigned version in NEC PrivateNet's SocksPlus implementation. The application level proxy differs from circuit level proxy because it is a dedicated proxy for a single protocol, such as SMTP or telnet. Thus, it understands the underlying protocol and can make determinations about which commands and actions should be allowed. This allows the application level proxy to be made very secure, but at the cost of implementing a new set of software for each new application protocol. Also, it can sometimes be difficult to implement such proxies in a transparent manner (but then you do not always want such proxies to be completely transparent, for example, a telnet proxy is likely to include some kind of authentication). In terms of which technology is more secure, I agree with the people who told you that proxy servers are more secure. However, when you look at the bigger picture, you will need to take into account the overall level of security in the existing network. If you evaluate the security of the firewall itself, and ignore the rest of the network, you might end up with installing an iron door in a cardboard house. In a number of instances in which I have evaluated the security of a firewall, I have found that it is almost a moot point due to lack of security in other areas. Selection, installation, and configuration of a firewall must be part of an overall strategy defining and implementing an appropriate level of security for the organization. In other words, although a firewall based on packet filter technology may be less secure than a proxy-based one, it might still be the most appropriate overall choice for an organization. Also, a firewall can only enforce access control rules for a connection that parses through that firewall. It will do no good at all if the intruders can get in through other means, for example through modem connections. Therefore, when evaluating firewalls (whether they are commercial or freeware implementations), you must do that evaluation from an overall perimeter security point of view. This entails all outgoing network connections, including connections to any computer or network that is not part of the local administrative domain, all modem connections, and also nontechnical areas related to what is often called social engineering. In my opinion, it is not possible to build a firewall that cannot be breached. Even a firewall that is very strong from a technical perspective can be breached by bribing one or more of the people working for the victim organization.
About the Author
Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at bjorn@sysadmin.com; or by phone at (408) 241-3111.
|
We currently archive all printer requests on our UNIX
system in order
to have the ability to regenerate reports when they
fail. The problem is
that we get too many requests for reprints, and many
users only want a
partial reprint. I considered setting up a structure
that stores users'
print requests in their home directories and then gives
them a utility
to reprint it, but rather than reinventing the wheel,
I'm wondering if
there's a package that does this. The other issue to
consider is that we
print jobs automatically on weekends. These jobs have
a high reprint
rate because they are printed unsupervised. We could
put in a script to
change to a specific user thereby storing the print
job in his/her
directory, but maybe there is an even better approach.
Based on the information information you have provided,
it looks as if
you are attempting to provide a technical solution to
what essentially
is a people problem. In my experience, this never works.
If I were
working with you as a consultant on this problem, the
first thing I
would ask is why people are requesting so many reprints.
Your question
indicates that the reprints present a severe load on
your system, and if
the need for the reprints can be reduced, then you have
a better (and
simpler) solution than any reprint management system
you can invent
would be able to provide.