"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis,
Starshine Technical Services, http://www.starshine.org/

Can't Telnet to Red Hat 5.0 Server

From: Brad Lackey,

I am trying to set up a LINUX web server for Colorado State = University - CIS Dept. I have Red Hat 5.0 Installed with user accounts = set up but I cannot telnet to the machine. I get the login prompt, but = none of the user accounts that I have created seem to work, including = root. they all give me "Login incorrect". I was wondering how to fix = this validation problem...
Thanks, Brad

First I'll have to assume that you installed RH5 on a fresh x86 machine with no previous OS, and that you've just installed the package from a CD and have yet to apply any upgrades or patches to it.

If that's the case -- fire up the old browser and go to Red Hat's "Errata" pages at:

http://www.redhat.com/support/docs/rhl/rh50-errata-general.html

There are about 30 upgrade packages there -- including fixes for the utils package (fixes 'vipw' command), and glibc (the core c libraries which most of your other programs depend upon through the magic of shared libraries).

I don't see a specific entry for the problem that you're describing -- and I haven't upgraded any systems to RH5 yet -- so I don't know if this problem is generic.

A quick search of Yahoo!/Alta Vista and DejaNews doesn't show a match to exactly this problem either -- but it does show that telnet to RH5 boxes is working for many people. (Many of the problems reported have to do with long delays, caused by the "double-reverse lookup" that TCP Wrappers uses to prevent most varieties of spoofing). So, given that the search string "+red +hat +5 +telnet +login" didn't give us an easy answer we'll have to do some troubleshooting.

Let's start with some questions:

Does your syslog (/var/log/messages or /var/log/security) tell you anything?

Have you run pw5conv to enable shadow passwords?

If you run 'vipw' ('vi' the /etc/passwd file) do the password hashes appear there?

Have you installed a different PAM (pluggable authentication modules) or modified its configuration (any of the files under /etc/pam.d/)?

I didn't see a new PAM RPM up at the site listed above -- though things like the initscripts package and the glibc package might help.

If these questions don't help you find the problem and resolve it I'd suggest that you grab a Red Hat 4.2 or a S.u.S.E., Debian or other distribution and install that. If you use Red Hat 4.2 you'll want to fetch all the upgrades for that -- and you might be able to install specific RH5 rpms (including the glibc which *should* co-exist cleanly with the libc 5.x that most (almost all) Linux distributions prior to RH5 rely on).

As a support volunteer I find Red Hat's decision to push the release of "Hurricane" out the door at the end of last year to be abominable. I suggested to them that they do a 4.5 first -- and wait until about March of this year for a 5.0 (hoping that glibc would be better understood, that PAM would move much closer to 1.0, and that the 2.2 kernel *might* ship by then).*

*** Please note: I don't have any "inside" hints as to when any of these event will occur. I don't know how long it will take to go from the 2.1.8x kernels through the inevitable 2.1.99.x flurry and get to 2.2. I read the kernel mailing list and cross my fingers like everyone else. Obviously Red Hat Inc (the company) and Caldera, and Yggdrasil, and many other organizations and individuals can help. If I were a programmer I might be able to help more.

However, I was sure that 5.0 was too soon -- and the 34 Mb of upgrades and patches that were available as of last November needed to be released on CD to save the 'net a bunch of bandwidth. (I occasionally cut these and similar new stuff onto CD's using my ISDN line and my CD-R and give them away. I'm hoping to give one or two away at tonight's SVLUG (Silicon Valley Linux User's Group) meeting where we'll be hearing from Bruce Perens of the Debian project, and Eris S. Raymond, whose paper on the "Crystal Cathedral" was cited as a key part of Netscape's decision to release their sources)).

I'd like to see Red Hat adopt a subscription model, where I can get monthly update of their "updates" and "contrib" mirrors for about $10/month. (I suppose it doesn't *have* to be Red Hat to do this, anyone with a CD-R and a reasonable trickle feed from the 'net could do it. Though the economies of scale don't work until we get a few hundred subscribers).

Heck, if there's enough interest I'll do it.

In any event, I hope one of these methods works.

At the risk of starting serious flame wars and raising questions about my "loyalty to the cause" (which cause we're not sure) I'd also suggest that you look at the OpenBSD (and FreeBSD and NetBSD) distributions if you don't have a specific reason for picking Linux for this application.

Linux is the most popular of the free Unix' -- but it's not the only one -- and it's not necessarily the best for all applications. OpenBSD, in particular, seems to be very well suited to multi-user "student use" and "computer lab" use. This is because Theo de Raadt and his team have found and corrected a large number of buffer overflows and other vulnerabilities in the sources for FreeBSD and NetBSD (and probably in the sources of many Linux utilities as well).

Obviously this depends quite a bit on your intended applications. However, if I was setting up a general use shell account system for a school lab, an ISP, or a USENIX "terminal room" I'd probably suggest OpenBSD.

For personal workstations I think Linux holds the edge in performance and applications availability.

--Jim

Use the Source, Luke!

From: SuatChoo Lua,

Here there something that maybe you can answer me. From where i can get the information about Linux File system,memory managemant,and scheduling algorithm. Thank you!
coco

In many ways I'm not the best person to answer this question. Remember that I am not a coder -- and I haven't contributed any programming to the Linux kernel (which I'm sure we all appreciate). However, I've read a bit of it -- and will offer some opinions.

If you want deep information about -- technical details -- about Linux filesystem, memory management, and scheduling internals than the obvious thing to do is to read the sources.

/usr/src/linux/kernel/sched.c is about 1700 lines long (about 80 pages). There are about 30 .c files under /usr/src/linux/fs (the filesystems directory) -- and about 160 .c files under that whole tree. Linux supports many different filesystems -- although the one that is considered to be "native" to Linux is the ext2fs.

A variant of this filesystem has been adopted by the FSF for their ongoing HURD project (which is a microkernel OS for which rms and the Free Software Foundation developed gcc, GNU emacs, and most of the applications and utilities that make Linux possible).

The code for ext2fs is about 5000 lines. Probably the simplest filesystem that ships with Linux is the Minix compatible one. Minix is a simple microkernel operating system written by Andrew S. Tanenbaum for inclusion with (and publication in) his text book on "Operating Systems: Design and Implmentation." That book is one of the seminal works on the topic -- and has probably been studied by every major contributor to Linux.

The memory management code is in /usr/src/linux/mm. It probably shows off the greatest innovations in the Linux kernel. The aggressive strategies here allow a Linux kernel to operate within a pretty modest footprint despite the "freeping creaturism" that some of its detractors lament.

Where to begin:

I'd start by reading Tanenbaum's book (there's a second edition where he's joined by Albert S. Woodhull). Just read the first half to get all the key concepts. The latter half of the book are the sources for Minix; which don't relate to Linux.
I'd then pick up a copy of the The Linux Kernel Hacker's Guide by Micheal K. Johnson (should be at any good LDP -- Linux Documentation Project -- mirror site).
Then grab a copy of The Linux Kernel by David A. Rusling and LINUX Kernel Internals by Michael Beck et al. (This last one is published by Addison Wesley -- the others are available online -- and published/printed in various editions of _The_Linux_Bible_, _Dr._Linux_, etc).

After you've read some of those the kernel sources will hopefully make sense. Keep in mind that many of these things are still changing in the form of patches and in the newer 2.1.x kernels. For example there is a "evolution scheduler" which allows you to experiment with different scheduling algorithms for your Linux system. You can learn quite a bit about current Linux limitations by perusing Kurt Huwig's collection of "unofficial" Linux patches at http://linuxhq.sigkill.org/ or http://www.huwig.de if you'd like to read them in the original German. These include several experimental shedulers and memory management tweaks (like one that search for duplicated pages and aliases them to one another on the fly).

I hope you find all those interesting and informative.

--Jim

'ifconfig' to Troubleshoot Dropped Ethernet Packets? Uh-Unhg!

From: Chris Oliphant,

I have a HP Vectra XM2 4/100i computer with an onboard PCnet/32 ethernet chip running Red Hat Linux 4.0, kernal version 2.0.18. I currently am having problems communicating over the ethernet connection for the last three days. I want to use IFCONFIG to troubleshooting the problem, but don't understand how to use the command's output. My problems are excessive receive packets being dropped and excessive transmit errors. I am able to ping the onboard chip, and the port connect is good with other systems connected to it. But when I connect my Linux system to the port, I have problems. Please advise. Thanks for any assistance you may provide. --Chris Oliphant

'ifconfig' is the "interface configuration" utility. It isn't a troubleshooting tool. I'd usually 'ping', 'tcpdump' and 'netcat'* or 'kermit'* for troubleshooting this sort of problem.

netcat is at ftp.avian.org (It is a little "swiss army knife" for TCP/UDP -- providing a simple facility for scripted TCP connections and transfers).
kermit (C-Kermit) is at kermit.columbia.edu (Aside from being a venerable file transfer protocol and serial communications packages, C-Kermit is also a telnet/rlogin client -- offering file transfers, scripting, debugging, and log-to-file features over TCP connections).

Based on your question here's a few standard support questions to echo back:

"for the last three days"? What happened then or before then? Did the link work fine before then? Did you upgrade your kernel? Change drivers? Add a new video card? Did this kernel/driver/module ever work acceptably with this ethernet card? With this system's mixture of other components? With a similar (so-called "identical") system?

Excessive errors on an ethernet line suggests the following sorts of problems:

high collision rates -- Are there other boxes on your LAN segment that might be utilizing an excessive amount of the bandwidth? How many systems are on this segment? What applications are they running (particularly network intensive)?
As an example if you put a few xterminals or diskless workstation on a network and they fetch all of their X resources, binaries and libraries over the wire (rather than tftp to a local RAM disk for example) then you can flood an unswitched ethernet segment in no time.
hardware problems with your card or someone else's (on the same network segment) --
It is possible that some ether card on your segment is broken and "chattering" (generating spurious signals which corrupt the data frames (network layer "packets") from other cards. This is likely to show symptoms across the entire segment (all the machines will be affected). It is also possible that any particular card is damaged. It is also possible for the problem to be in a particular wire (are you using 10BaseT, coax/thin net, or (heaven forbid!) thicknet?), or even a particular port on one of your hubs (repeater, concentrator, whatever the "term du jour" for that thingie-me-bob is). It could be as simple as "someone kinked the wire by running it over with their chair wheel."

A good way to test for this is to get an ethernet "cross over" cable (sort of a "null modem" for 10BaseT) and plug it between the problem system and a known good one. This bypasses all the intervening components to help isolate the problem.

(Basic troubleshooting 101: identify all components, eliminate as many as possible for testing, continue simplifying the configuration -- and possibly the tests -- until something works, re-add components back until failure. That isolates the problem.)
bad driver or configuration -- If this has never worked under Linux (or under the specific kernel your working with) you should boot under some other OS and use whatever diagnostic utilities HP provides. If those work and Linux still fails it suggests a software configuration or driver problem. If you had an older kernel that did work without a problem, try booting with it and running your tests -- it's always possible that the card is broken in someway that only shows up under conditions that don't occur from DOS or Win '95. It's also possible that something in your kernel is broken.
Naturally you'll also want to try a 2.0.33 or 2.0.34 kernel to see if that helps.

As I've pointed out -- you need to do basic troubleshooting in situations like this. You also want to ask yourself: "Have I provided enough information for anyone (short of a psychic) to answer this question?"

--Jim

Cthugha

From: kim angel,

Could you please tell me when Cthungha will be available for Win95? Thanks!
Kim Angel

Sorry. Can't be much help there. I presume you mean Cthugha (no 'n') which would be the audio/video amusement (turn your $3K multi-media system into a $40 "discoteque" light).

Hmm....I detect a tad of dissatisfaction with the product!

I've never run it. I have a lack of interest in the class of software. I had to look it up in the LSM (software map) to remember what it was -- since I mis-remembered it as a "game").

I have no idea if or when it would be available for Win '95 -- or even why anyone would port it. However, I'd contact the author/maintainer (should find his/her/their name(s) in the man pages or docs).

What I am seeking is a program that is capable of applying digitized animation choreographed to audio sequences. Could you help me with this?

I'm the "Linux Answer Guy" (or, to be more specific and a little less pretentious, the "Linux Gazette Answer Guy").

It appears that Cthugha *is* just what you want -- for Linux. I'm not the "Windows '95 Answer Guy." A role which I probably would be wholly inadequate at since I don't run it on any of my systems and I don't like what little of it I've had to run.

Despite this I can offer you a pretty simple piece of advice:

Ask the author.

Another possibility is that you could try the port yourself. I'm not sure what the licensing of Cthugha and its sources is -- but it's probably GPL. That license lets you port it to any OS or platform you like -- or pay anyone else to perform the port to your specs.

If you should find that the port to native Windows API's is too difficult you could try DESQview/X (which offers X Windows API's over DOS) or you could try OpenNT (from Softway Systems at www.softway.com). OpenNT offers reasonably complete Unix API's -- and some X Windows if I heard correctly -- and runs under NT. I have also heard of several developers tools that purport to compile Unix/X Windows code into native MS Windows API's. However I don't have any experience with them, nor any personal interest in them.

-- Jim

xdm Login doesn't!

From: Cesar Augusto Kant Grossmann,

I run my Linux Box in the "graphics mode" (changing inittab accordling) = bu I can't login as normal user. When I try to login as normal user, the = screen flickers like a logout in the X, and the login screen comes back.

This is also referred to as "using 'xdm'" (X Display Manager) which provides a GUI login to X.

You don't mention what sort of system you have (which distribution what architecture/platform, what packages you've installed or updated, etc). You also don't mention whether you can login via a text mode console (VC/VT) or via telnet or a serial line.

If you can, the problem is likely to be a mismatch between your 'xdm' binary and the authentication model/settings that you have for your other 'login' modes.

This is one area where the FreeBSD crowd definitely had a better model. Under Linux you can use the old-fashioned (traditional -- and insecure) authentication mode where the hashes of your passwords are stored in the /etc/passwd. Alternatively you can install or enable some variation of the "shadow" suite. This removes the password hashes from the /etc/passwd file and stores them in a different file -- one which is only accessible to privileged (SUID) programs -- and not readable by normal users.

The purpose of all that is to make the system more resistant to dictionary and cryptanalytic (brute force or otherwise) attacks. In other words using the 'shadow' options is more secure than allowing normal users to just snarf the hashes up, and copy them to a machine running 'crack'.

The problem is that there are many programs that authenticate users under Unix/Linux. In addition to login there's xdm, ftpd, xlock, vlock, screen's lock feature, popd, imapd, the passwd command etc. In FreeBSD they modified the libraries -- and ensured that all the programs were linked against the same shared library. This hides the details -- because the library calls that "getpwent()" (get password file entries) automatigically merge the passwd hash from the shadow file (called /etc/pwdb.master? or somethine like that -- in FreeBSD) if that file exists and is readable.

Thus unprivileged files on a shadow enabled get pw entries with an "obscured" password field (usually just a "x") while privileged (SUID) program get a merged one that's suitable for comparison to a properly crypted/hashed password as provided by an alleged user.

The other advantage to the FreeBSD method is that changing the hashing algorithm (from the traditional 56-bit DES on a string of zeros -- to a MD5 sum) is relatively easy -- only has to be supported in one place (the shared libraries) and doesn't require that all the other programs be changed. (Another feature of the FreeBSD password/account management libraries is that they support dbm hashes of the account names -- meaning that *huge* lists of accounts are possible without suffering a "linear" increase in login/authentication response times)

For now Linux has three different, and partially incompatible account/authentication schemes:

Traditional /etc/passwd files
Shadow suite (still with flat text files)
PAM and libpwdb (dbm files and modular authentication model).

The frustrating thing is that these can all work together do some degrees -- a pwdb system maintains a set of text flatfiles that are sync'd to the dbm/hash tables (these hashes are the indexed/search type -- as opposed to the cryptographic variety that I referred to earlier -- like 56-DES and MD5).

Although Red Hat has shipped their last 2 or three releases with PAM -- it isn't quite all there yet. The most recent version of PAM is about 0.63 (beta). However -- if you installed a recent Red Hat Linux (4.2 or 5.0 with patches) you should be able to use its xdm and all of their stock utils without trouble.

If you compiled your own 'xdm' or fetched it from somewhere you should consider recompiling it -- but looking for options that relate to "shadow" support.

What seems to happen? Where I can find more informations about these? A FAQ or something like...

I'd start by reading the Shadow HOWTO. I'd also suggest a web search on PAM (pluggable authentication modules): Here's some URL's I have for them:

Andrew Morgan's Page: http://www.kernel.org/pub/linux/libs/pam/
The Linux-PAM System Administrators' Guide: http://www.math.muni.cz/linux/Linux-PAM/html/pam.html
PAM - Pluggable Authentication: http://www.redhat.com/linux-info/pam/
PAM specs -- OSF RFC 86.0: http://sysadm.sorosis.ro/devel/pam/rfc86.0.txt

It's a good idea to read about PAM since several other Unix flavors are also moving towards it (currently appearing in Solaris and HP-UX, at least).

Sorry for my bad English, but I think it's better than your Portuguese...

Undoubtedly your English is better than my Portugese -- or even my French (I've never studied the former and only had a couple of high school years of the latter). --Jim