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

Contents:

• Netscape Mail Crashing
• Slackware Help
• Netscape /var/spool/USER
• Getting Rid of Virtual Screens
• diald's niche
• Upgrade to Red Hat 5.0?
• Red Hat Linux and WABI and other things
• Linux as a PDT

Netscape Mail Crashing

From: Jim Kelley, the-jim@swbell.net

I've been running Netscape Communicator 4.04 on my RedHat Linux system since the day it came out and yesterday it started crashing whenever I check for new messeges or try to go to a newsgroup. I've deleted NC4.04 and re-installed it but to no avail. Any suggestions?

When you removed NC4.04 (which I didn't know had been released yet -- I'm still using 4.03) did you also remove your ~/.netscape directory tree?

What happens if you try it from another account on the same system? What happens if you use different e-mail and newsreaders? (elm, pine, emacs' mh-e and/or tin, nn, trn, or emacs' Gnus for respective examples).

I would suspect a data or configuration file corruption. Many programming practices that I most loathe and detest have to do with a lack of robustness and simple error messages with regard to corrupted input. Is it really that hard to have a switch that logs each input source like: "Reading configuration from ~/.netscape/foorc....." and "Bounds error at ~/.netscape/bar.conf offset 0x2AFF9A77"? I haven't looked at the innards of NS Comm's data files -- I wouldn't use their mail and newsreaders since I'm very particular about my mail and netnews -- and I need extensible, configurable, text mode capable systems (so I use emacs' mh-e and Gnus).

--Jim

Slackware Help

From: Ralph, RPMAXEDGE@aol.com

HELP!!!!!!!!!!!!!
Recently I installed Linux Slackware version 3.2, everything loaded fine, but I really run into problems when I set up the password for the root, for some reason the one i register doesn't allow me to log in. I have problems on how to mount the /root and remove the existing password from the /etc/shadow. I install linux with partitions for a SCSI hardrive sda1 sda2. I would really appreciate some few hints to solve this problem.. Thank YOU VERY MUCH.

--Ralph

I haven't used any of the newer Slackware systems -- so I don't know if there's anything specific to their system that would contribute to or cause this problem.

The general way to fix this sort of problem (lost root password) is to boot from a rescue diskette (or from an "alternate root partition") mount your normal root partition (let's you put it under /mnt/oldroot) and then simply edit the mnt/oldroot/etc/passwd file -- and maybe the corresponding shadow file).

Another trick is to use the chroot command instead of editing the passwd files directly. Basically you can follow the mount with a command sequence like:

		cd /mnt/oldroot/ && usr/sbin/chroot . bin/sh 

		passwd 

A properly maintained alternative root partition should have extra copies (mirrors) of the whole /etc directory from your production root partition. This makes recovery from errors *much* easier. On some systems you may be able to use a removable drive (LS120, Zip, Jaz, magneto-optical, Bernouli, Syquest, DynaMO, whatever) as your alternative root system.

-- Jim

Netscape /var/spool/USER

From: John Liebenrood, k7ro@teleport.com

I'm running Redhat 4.2 with Netscape 3.01. I can send mail fine but I can't receive mail. I don't understand how to configure my /var/spool/USER. I've used chown mail.mail and chmod 01777 on USER file. But still can't get mail to come in... all talk no listen

--john

Do you have a POP account? Are you trying to read you mail from the localhost? Where is your localhost supposed to get it's mail from?

Normally 'sendmail' (or smail, deliver, or procmail) appends messages to your spool file. 'sendmail' gets your mail via SMTP or from your UUCP system (depending on your configuration and your ISP/account type).

There are a bunch of factors that anyone would need to know before answering your question.

Netscape is normally configured to fetch mail via the POP protocol and to send it directly via SMTP. If your system is already configured to send and recieve mail (i.e. you can use other mail user agents (MUA's) like elm, pine, mh, etc) then you should be able to configure Netscape to use "localhost" (the loopback interface -- internal to your own system).

Personally I won't use NS Nav. (or Comm.) as a mail or news client. I absolutely require a text mode interface

-- Jim

Getting Rid of Virtual Screen

From: bmiles@intergate.bc.ca

Hi, how do i get rid of the virtual screen under x windows, it's bloody annoying!! I've tried disabling it under install and I've even tried resetting my resolution size, please help!!!

Assuming you're using XFree86 you'd edit your XF86Config file (which might be /etc/X11/XF86Config or might be something more like /usr/X11R6/lib/.... or something).

Find the Screen section for the device driver and mode you're using, look for the display subsection that applies you your monitor and modify the "Virtual" line thereunder.

If you've tried that (if that's what you mean by "resetting my resolution" or "disabling it under install") than it's possible that you're using a different X Server than I think you are (Xig, or Metro-X or something) or that your installation or distribution is using a config file in a different location than you think it is.

The man pages for 'X', 'startx' and 'xinit' may help -- in particular the XFree86 servers allow you to specify an option of -xf86config file -- which allows you to explicitly over-ride the system wide configuration (and is a great reason for security concscious sysadmins to limit the execution of X to some trusted local users -- and maybe use xdm).

I found this option in XFree86(1) (that's the XFree86 man page in chapter one on my man pages). Don't confuse it with the -config option referred to in the XServer(1) man page. That option just says that more *command-line options* are stored in a file. The XServer man page refers to options and configuration information that should apply to any Unix X Windows display server. The XFree86(1) page refers to the extensions which apply to the servers written as part of the XFree86 project. The various XF86_* man pages refer to the features that are specific to specific servers (that is the ones which are compiled for a given video card or chipset).

You're only running one binary -- yet three man pages apply to whichever one you're using. This is unnecessarily confusing -- and one of the books I've perused (on Unix, X, or Linux) cover this sort of thing. So you have to wander through lots of different man pages and /usr/doc/* files without a clear roadmap.

I'm hoping that some future distribution (maybe the Red Hat 5.0 that's supposed to be shipping in the next couple of weeks, or the next Debian) will have a really good set of HTML (lynx clean!) documents, served by default off of the initial localhost webserver which takes a top down, organized approach to educating and informing us about all the power and choices we have in Linux.

-- Jim

diald's Niche

From: Pollywog, caldera-users@rim.caldera.com

Put it anywhere you'd like. The .rpm version installs into defined sub-directories, but keep the .rpm file anywhere you like. I have /usr/local/packages for tarballs and .rpms....

I recommend that SA's use a /usr/local/from directory tree. You can then have a set of directories named after your favorite FTP and web sites and after the volume names of your favorite CD's.

When you download/fetch a file -- put it into a directory that reminds you where you got it from such as:

/usr/local/from/sunsite/ /usr/local/from/redhat/ /usr/local/from/ftp.replay.com/

... etc.

Now when you want to upgrade a package you can see where you got the previous version from -- and consequently you have a headstart on where to look for upgrades.

This technique is also handy if you read an alert about a compromised (trojan) package -- you can easily see where *you* got your copy from.

For files you install off of the CD -- create a directory name that reminds of you which CD it is like:

/usr/local/from/cd/MOP/ (Mother of Perl) /usr/local/from/cd/rharchive.fall97/

... etc.

Now you just put symlinks from that directory to your usual CD-ROM mount point (ln -s /mnt/cdrom/dir/foo foo).

This creates a tree of "broken" links -- but it tells you where to find the source file if/when you need to rebuild.

As you can probably see this technique is really a "poor man's HSM" (hierarchial storage management system). You can also extend this idea to migrated data files from your home directories to removable media (such as Zip, Syquest, MO, and CDR devices).

It's also a very handy form of self-documentation in businesses where you may have many sysadmins or you may have various consultants "stomping" around on your systems.

-- Jim

Upgrade to Red Hat 5.0?

From: Jason Welsh, jwelsh@mci.net

hey, im running an older 4.something version of Red Hat and was wondering if I just wanted to upgrade it to 5.0, do I need to download certain RPMS or do I need to get the whole thing? or get it on CD.. just curious if there was a shortcut I could take..

--Jason.

I would get the CD (in fact I did -- but I haven't run the upgrade yet -- want to finish some work and do an extra backup first).

CD's save lots of bandwidth and save lots of time.

If you don't need the commercial packages that come with Red Hat (the BRU and Metro-X) you can wait a month or so for the "Archives" set to come out -- which is about $20 (less than half the full version).

-- Jim

Red Hat Linux and WABI and other things

From: peter@trimatrix.net

I have RedHat Linux v5.0 (kernal 2.x) ($49) and (silly me) found out that Caldera OpenLinux Standard ($399) supports WABI for Windows 3.1 apps, FreeDOS (or is it DOSEMU??) for DOS apps, and NetWare 3.x/4.x client supporting NDS (Network Directory Services).

WABI/Linux (a.k.a the Windows 3.1 Applications Binary Interface) is available separately from Caldera. It is a commercial package -- and it should install on most Linux systems without much trouble.

There's also WINE ("WINdows Emulation" or "WINE is not Emulation" -- take your pick of acronym expansion). This is a freeware project to implement enough support for the lower level Windows API's to allow Linux (and other Unix) users to install MS-Windows and run Windows programs.

I've heard that it is also possible to run Windows 3.1 in "standard mode" under DOSEMU/MS-DOS. I'm not sure if that works under other DOS variants running under DOSEMU.

OpenDOS is Caldera's release of "Novell DOS" (which was formerly "DR DOS" -- from Digital Research). Caldera aquired the licenses and rights to Novell DOS when Novell decided to "refocus on its 'core' markets" (and practically gutted itself in the process). In fact Caldera's "Network Desktop" (their distribution that preceded the OpenLinux/Base and OpenLinux/Standard) was originally a research project at Novell.

OpenDOS is partially commercial -- it is free for personal use (or for students, or something like that -- read their web pages for details). It has little to do with DOSEMU. OpenDOS is available on CD for about $30(US).

DOSEMU is really a bit of a misnomer. Technically it's a BIOS emulator which can be used to run any x86 "real mode" operating system (such as CP/M-86 or some versions of Forth). When you install DOSEMU you also have to install some copy of DOS (MS-DOS, PC-DOS, OpenDOS, whatever) to get any practical use out of it. DOSEMU includes several DOS programs which connect to the underlying Linux system. This allows one to access Linux directories and NFS mounts as DOS "network" drive letters, and do other things like that.

FreeDOS is a different project -- you can learn more about it at http://www.freedos.org. They are quite Linux friendly -- but I haven't played with their release (and I've barely touched DOSEMU or Caldera's OpenDOS) so I can't say much about it.

Regarding Netware access from Linux:

Caldera's Netware client access (with bindery and NDS support) is only available as part of their OpenLinux Standard (as far as I know). I've heard that some people have successfully installed the clients on other Linux distributions. However it appears that you are legally required to purchase the commercial COL/Standard (Caldera OpenLinux is often called COL by participants of it's mailing lists).

There are also a couple of free packages that implement some Netware protocols for Linux. 'ncpfs' is one that allows you to 'mount' Netware partitions in a way that similar to NFS. This is a system-wide mount (unlike the Caldera netware clients where each user has unique "virtual" mountings that are not visible from other concurrent processes on the system.

There's also the mars_nwe (Netware emulator) that implements a subset of the Netware fileserver protocols -- allowing DOS and other systems to access portions of your Linux filesystem(s) using the Netware clients (similar to 'samba' for Windows for Workgroups/LANMan/NT functionality).

I would like to know if this support can be added to RedHat Linux by downloading this stuff from somewhere, and recompiling the kernel? Can you help? I'm new to RedHat and have not yet gotten an answer from them.... If not, can you direct me to where I can inquire? This is a quest to make use of our 486 computers at work (and just need to know) by running Linux, and still support some things like Windows 3.1x Lotus Lotsuite, etc., which Caldera claims to do, but I would like to find out how much trouble it would be to add support to Redhat.....

In general, anything you can run under Caldera you can get to run under Red Hat or any other reasonably recent Linux distribution.

Since Caldera, Red Hat, Craftworks, and a couple of other Linux distributions use the same package management system (the RPM -- or "Red Hat Package Manager") sharing packages among them is somewhat simpler than installing a Debian package or Slackware "tarball" would be.

I'd look at any FTP mirror of Red Hat's "contrib" directory for the lastest dosemu "rpm" and install that. You'll probably find one of these on your set of Red Hat CD's in addition to the ones online. You can check the online directory for updates and recent additions.

-- Jim

Linux as a PDT

From: Karl Rossing, gtivr6@pangea.ca

Linux as a PDC (Primary Domain Controller), NIS/NIS+ Master -- etc.

I was wondering if it is possble to get windows 95/NT to authenticate to LINUX (using nis or nis+). I'm really getting tired of adding accounts on the nt boxes for the linux boxes(for smb)...Is there any commercial software availible?

It sounds like you're asking fundamentally different questions here.

In your subject you refer to using Linux as a PDT by which I presume you meant a PDC (Primary Domain Controller). Here you refer to using NIS/NIS+ -- which would involve adding client support (third party software) to all of the NT/'95 boxes.

A broader questions is:

What network authentication and directory services system/model/architecture should you use?

This is a sticky question with no easy answer.

A simpler question is:

How can I configure my MS client machines (NT and '95) to use my Linux system's account information for access control and authentication?

I'll provide some thoughts on each of these questions after commenting on the rest of your message:

I know of p-sync [http://www.m-tech.ab.ca/psynch/index.html]

I glanced at their web pages and was not impressed. They have almost no text and are almost completely unreadable for Lynx users. They also don't offer any functionality in their demo -- which is just a mockup of the GUI (crippleware).

and NSGINA [http://www.dcs.qmw.ac.uk/~williams/] which seems a bit of work to setup...

That would "NISGINA" This is by Nigel Williams -- apparently derived from work by Doug Scoular(*). It is apparently released under a BSD'ish license. So this is much more promising than the p-sync package right off the bat.

* (http://www.arch.usyd.edu.au/~doug/gina.html)

GINA (graphical identification and authentication) is the NT DLL that manage logins at the NT console -- there are several different GINA's -- one from Novell for NDS, one from MIT for Kerberos, another similar one for NT-AFS (Transarc's distributed filesystem -- which uses a Kerberos 4 authentication model) etc. Here are some related URLS:

NT GINA related information: http://web.mit.edu/cartel/ntgina.html -- very informative -- leads to all the rest that I found.

ND_GINA - An alternative authentication method for Windows NTr, http://www.nd.edu/~dobbins/ntarch/nd_gina_doc.html

NT/UNIX Integration with Doug's GINA replacement, http://www.arch.usyd.edu.au/~doug/gina.html

The problem with GINA is that it doesn't appear to be available for '95 (or earlier versions of Windows or DOS). That may be a show stopper for for this approach

I can't recommend in good faith that you upgrade you Win '95 systems to NT (since that just buys you in further to this proprietary OS model -- and just worsens your dilemma when '98 and NT 5.x ship).

I'm not really looking for passwd syncronisation, i'd like to consolidate it to the linux box, because the users use both linux/95/nt. nuff said, thanks.

I don't think nearly 'nuff's been said about this topic. There are a large number of directory service and authentication methods that are vying for control of your network. Each as its own security implications -- making them co-exist is difficult from the start, and a constant drain on administrative time and resources -- and having them running concurrently usually means that the weakest link prevails in your security model.

There's an excellent white paper about this at Cygnus Solutions:

http://www.cygnus.com/product/unifying-security.html

That aside, some of your choices are:

• Microsoft's WINS (and its PDC/BDC domain model)
• Kerberos and Cygnus Kerbnet
• NIS/NIS+
• RADIUS/TACACS
• LDAP (lightweight directory access protocol)
• Netware NDS, Banyan StreetTalk, etc.
• Host based security -- custom synchronization
• scripts.

Overall I think I'll like CODA best when we have a reasonably Linux server and client for it.

More more info on the CODA project at CMU browse through their mailling list archives at:

http://www.coda.cs.cmu.edu/maillists/linux-coda/0175.html

I could rant for sometime about the security models of the various network/shared filesystems -- but it's late so let it suffice to say I like that even less than the choices for DS and authentication. So far I think I like TCFS (transparent cryptographic filesystem) the best for security -- though I'm quite concerned about its performance costs.

I presume you're using Samba on your Linux server(s) to provide file services to your Windows clients. From a glance at the Samba Meta-FAQ and some of its other pages it looks like you could just let Linux/Samba manage the accounts for your whole network.

Here's some links that relate to that:

Samba: User accounts http://samba.anu.edu.au/samba/docs/smb_serv/html/smb_se-4.html#ss4.1

Samba Server HOWTO http://samba.anu.edu.au/samba/docs/smb_serv/html/smb_se.html

(*Note: if I read this correctly -- Samba can't currently be a "password server." This seems to mean that it can't act as a PDC/BDC (backup domain controller) for NT systems to refer client authentication requests through).

It looks like the future will hold some sort of LDAP and Kerberos -- for NT and many other OS' and packages. This would be fine -- if it weren't for the inevitable politicking and kneebiting that the various commercial vendors are going to do.

The problem is that everyone's version of LDAP (directory services) and Kerberos (authentication) will be just different enough that each vendor's OS will just *need* to be *the* server for *their* domain. They'll all make press releases about their "interoperability" -- and most will refuse to release enough details about their "extensions" for any other vendor (or freeware programmers) to implement them elsewhere.

I guess it will take a few years after the initial deployment for enough of this proprietary info to leak out (and/or be reverse engineered) to allow system administrators to actually have any semblance of a unified directory service and authentication system. The bugs and security problems will probably keep popping up for a long time after that (they've been popping up in Unix for 27 years -- and many of them are reappearing in NT now).

Meanwhile we're going to see a continuing explosion of servers and network applications (client server systems) that each require different user account (with associated group, token, and other information) and authentication information.

Worse yet, the various layers of management above us are already hearing the marketeers lies -- that the solutions are "already shipping" or "just around the corner." This is just what management wants to hear -- so many of them are believing it -- and planning their budgets and project schedules accordingly. A system administration disaster in the making.

Sorry I can't offer a brighter hope for the new year -- but I'm no marketeer.

-- Jim