Linux-Advocacy Digest #766, Volume #25 Thu, 23 Mar 00 05:13:06 EST
Contents:
Re: Bsd and Linux ("Peter T. Breuer")
Re: Bsd and Linux ("Peter T. Breuer")
Re: A pox on the penguin? (Linux Virus Epidemic) (Stefan Ohlsson)
Re: Giving up on NT (Bob shows his lack of knowledge yet again) (George Marengo)
Re: Giving up on NT (Bob shows his lack of knowledge yet again) (George Marengo)
Re: Windows 2000: nothing worse ("Erik Funkenbusch")
Re: Why did we even need NT in the first place? ("Christopher Smith")
----------------------------------------------------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.x,comp.os.linux.development.apps
Subject: Re: Bsd and Linux
Date: 23 Mar 2000 08:34:23 GMT
In comp.os.linux.development.apps Donovan Rebbechi <[EMAIL PROTECTED]> wrote:
: On 23 Mar 2000 05:40:07 GMT, Peter T. Breuer wrote:
:>I am hardly likely to forget to configure a new shell, having gone to
: What happens when you want to change confioguration ? You'd better
: remember to do it for every shell. Redundant configuration without
I have NO trouble doing so!
: some kind of integrity check is the last thing a systems administrator
: needs.
Err .. try for i in `cat /etc/shells`; do $i -c env; done
:>the trouble of adding it! But yes, it;s robust. The consequences of
:>losing the config file are that restrictions are lifted. The
:>consequence of losing libpam stuff is that nobody can log in. I.e.
: I am not clear how you're going to "lose" it all. Since there are
Try a system crash.
: several config files, it's unlikely you'll have an unusable system
: just because you mess up one file.
Oh. Try explaining that to my brand new suse 6.3 cdroaster machine,
which decided to crash a week ago and take out precisely something in pam,
leaving nobody, not even root, able to log in. (midn you, you'd
achieve the same effect with rm /etc/passwd! Try it! - that is a bug
in libc. Root must always be able to log in).
:>it does not fail safe.
: Nothing's failsafe. What happens if you lose /bin/login ? Either way,
If I lose /bin/login then I will execute a remote cp to put it back
(actually, I will execute a task on the machine to go fetch it and put
it back, since, yes, I DO have failsafe ways of getting to the machine,
even without login. Think NFS, for one thing, inetd for another).
: you could get back in, but it would require booting into single user
: mode.
Single user mode won't work without login. It requires a passwd, normally!
:>: Show me how to set memory limits with quota.
:>
:>Why should I? Use ulimit/limit. Show me how to set screen fonts with
:>pam!
: ulimit works differently with different shells. In bash, it doesn't
: work properly ( try ulimit -v ). Another problem is that (again) you
That's a common compile fault in distributed bash. It works fine in my bash.
: need to maintain the ulimit settings for all the different shells.
All = 2.
:>Try explaining me any single line, like, say:
:>
:> UNDERBREAD
:> INTELLOGIC
:> INTELLIGENT
:>
:>(the entire contents of /etc/pam_smb.conf) Yes, I know, OK, try a
: Huh ? My pam smb config looks like this:
: auth required /lib/security/pam_pwdb.so nullok shadow
: account required /lib/security/pam_pwdb.so
: I understand it just fine. If *you* don't, read the pam docs -- it's
: all there.
No, I don't understand a word of it. What does "auth" mean? Surely the
whole point is to control authorization! Why have a keyword? And
what does "required" mean? And which docs would you recommend?
/usr/doc/packages/changes/pam.changes
/usr/doc/packages/changes/pam_ldap.changes
/usr/doc/packages/changes/pam_smb.changes
/usr/doc/packages/ImageMagick/images/spam.gif
/usr/doc/packages/kbase/README.pam
/usr/doc/packages/pam
/usr/doc/packages/pam/Copyright
/usr/doc/packages/pam/html
/usr/doc/packages/pam/html/index.html
/usr/doc/packages/pam/html/pam-1.html
/usr/doc/packages/pam/html/pam-10.html
/usr/doc/packages/pam/html/pam-11.html
/usr/doc/packages/pam/html/pam-12.html
/usr/doc/packages/pam/html/pam-2.html
/usr/doc/packages/pam/html/pam-3.html
/usr/doc/packages/pam/html/pam-4.html
/usr/doc/packages/pam/html/pam-5.html
/usr/doc/packages/pam/html/pam-6.html
/usr/doc/packages/pam/html/pam-7.html
/usr/doc/packages/pam/html/pam-8.html
/usr/doc/packages/pam/html/pam-9.html
/usr/doc/packages/pam/html/pam.html
/usr/doc/packages/pam/html/pam_appl-1.html
/usr/doc/packages/pam/html/pam_appl-10.html
/usr/doc/packages/pam/html/pam_appl-11.html
/usr/doc/packages/pam/html/pam_appl-12.html
/usr/doc/packages/pam/html/pam_appl-13.html
/usr/doc/packages/pam/html/pam_appl-14.html
/usr/doc/packages/pam/html/pam_appl-2.html
/usr/doc/packages/pam/html/pam_appl-3.html
/usr/doc/packages/pam/html/pam_appl-4.html
/usr/doc/packages/pam/html/pam_appl-5.html
/usr/doc/packages/pam/html/pam_appl-6.html
/usr/doc/packages/pam/html/pam_appl-7.html
/usr/doc/packages/pam/html/pam_appl-8.html
/usr/doc/packages/pam/html/pam_appl-9.html
/usr/doc/packages/pam/html/pam_appl.html
/usr/doc/packages/pam/html/pam_modules-1.html
/usr/doc/packages/pam/html/pam_modules-10.html
/usr/doc/packages/pam/html/pam_modules-11.html
/usr/doc/packages/pam/html/pam_modules-12.html
/usr/doc/packages/pam/html/pam_modules-2.html
/usr/doc/packages/pam/html/pam_modules-3.html
/usr/doc/packages/pam/html/pam_modules-4.html
/usr/doc/packages/pam/html/pam_modules-5.html
/usr/doc/packages/pam/html/pam_modules-6.html
/usr/doc/packages/pam/html/pam_modules-7.html
/usr/doc/packages/pam/html/pam_modules-8.html
/usr/doc/packages/pam/html/pam_modules-9.html
/usr/doc/packages/pam/html/pam_modules.html
/usr/doc/packages/pam/modules
/usr/doc/packages/pam/modules/README.pam_access
/usr/doc/packages/pam/modules/README.pam_cracklib
/usr/doc/packages/pam/modules/README.pam_deny
/usr/doc/packages/pam/modules/README.pam_env
/usr/doc/packages/pam/modules/README.pam_filter
/usr/doc/packages/pam/modules/README.pam_ftp
/usr/doc/packages/pam/modules/README.pam_limits
/usr/doc/packages/pam/modules/README.pam_listfile
/usr/doc/packages/pam/modules/README.pam_mail
/usr/doc/packages/pam/modules/README.pam_nologin
/usr/doc/packages/pam/modules/README.pam_permit
/usr/doc/packages/pam/modules/README.pam_rhosts
/usr/doc/packages/pam/modules/README.pam_rootok
/usr/doc/packages/pam/modules/README.pam_securetty
/usr/doc/packages/pam/modules/README.pam_shells
/usr/doc/packages/pam/modules/README.pam_time
/usr/doc/packages/pam/modules/README.pam_unix
/usr/doc/packages/pam/modules/README.pam_unix_
/usr/doc/packages/pam/modules/README.pam_warn
/usr/doc/packages/pam/modules/README.pam_wheel
/usr/doc/packages/pam/pam.changes
/usr/doc/packages/pam/ps
/usr/doc/packages/pam/ps/pam.ps
/usr/doc/packages/pam/ps/pam_appl.ps
/usr/doc/packages/pam/ps/pam_modules.ps
/usr/doc/packages/pam/rfc86.0.txt
/usr/doc/packages/pam/txts
/usr/doc/packages/pam/txts/pam.txt
/usr/doc/packages/pam/txts/pam_appl.txt
/usr/doc/packages/pam/txts/pam_modules.txt
/usr/doc/packages/pam_ldap
/usr/doc/packages/pam_ldap/ChangeLog
/usr/doc/packages/pam_ldap/COPYING.LIB
/usr/doc/packages/pam_ldap/ldap.conf
/usr/doc/packages/pam_ldap/pam.d
/usr/doc/packages/pam_ldap/pam.d/chfn
/usr/doc/packages/pam_ldap/pam.d/chsh
/usr/doc/packages/pam_ldap/pam.d/ftp
/usr/doc/packages/pam_ldap/pam.d/gdm
/usr/doc/packages/pam_ldap/pam.d/halt
/usr/doc/packages/pam_ldap/pam.d/imap
/usr/doc/packages/pam_ldap/pam.d/kde
/usr/doc/packages/pam_ldap/pam.d/linuxconf
/usr/doc/packages/pam_ldap/pam.d/linuxconf-pair
/usr/doc/packages/pam_ldap/pam.d/login
/usr/doc/packages/pam_ldap/pam.d/other
/usr/doc/packages/pam_ldap/pam.d/passwd
/usr/doc/packages/pam_ldap/pam.d/poweroff
/usr/doc/packages/pam_ldap/pam.d/ppp
/usr/doc/packages/pam_ldap/pam.d/reboot
/usr/doc/packages/pam_ldap/pam.d/rexec
/usr/doc/packages/pam_ldap/pam.d/rlogin
/usr/doc/packages/pam_ldap/pam.d/rsh
/usr/doc/packages/pam_ldap/pam.d/samba
/usr/doc/packages/pam_ldap/pam.d/shutdown
/usr/doc/packages/pam_ldap/pam.d/ssh
/usr/doc/packages/pam_ldap/pam.d/su
/usr/doc/packages/pam_ldap/pam.d/WARNING
/usr/doc/packages/pam_ldap/pam.d/xdm
/usr/doc/packages/pam_ldap/pam.d/xscreensaver
/usr/doc/packages/pam_ldap/pam.d/xserver
/usr/doc/packages/pam_ldap/pam_ldap.changes
/usr/doc/packages/pam_ldap/README
/usr/doc/packages/pam_smb
/usr/doc/packages/pam_smb/CHANGES
/usr/doc/packages/pam_smb/COPYING
/usr/doc/packages/pam_smb/pam_smb.changes
/usr/doc/packages/pam_smb/README
/usr/doc/packages/pam_smb/TODO
/usr/doc/susehilf/pak_e/paket_doinst_pam.html
/usr/doc/susehilf/pak_e/paket_inhalt_pam.html
/usr/doc/susehilf/pak_e/paket_inhalt_pam_ldap.html
/usr/doc/susehilf/pak_e/paket_inhalt_pam_smb.html
/usr/doc/susehilf/pak_e/paket_pam.html
/usr/doc/susehilf/pak_e/paket_pam_ldap.html
/usr/doc/susehilf/pak_e/paket_pam_smb.html
/usr/doc/susehilf/raw_pacs/english/pam
/usr/doc/susehilf/raw_pacs/french/pam
/usr/doc/susehilf/raw_pacs/german/pam
/usr/include/security/pam_appl.h
/usr/include/security/pam_filter.h
/usr/include/security/pam_misc.h
/usr/include/security/pam_modules.h
/usr/include/security/_pam_compat.h
/usr/include/security/_pam_macros.h
/usr/include/security/_pam_types.h
/usr/lib/libpam.so
/usr/lib/libpam_misc.a
/usr/lib/libpam_misc.so
/usr/man/man3/pam_authenticate.3.gz
/usr/man/man3/pam_chauthtok.3.gz
/usr/man/man3/pam_close_session.3.gz
/usr/man/man3/pam_end.3.gz
/usr/man/man3/pam_fail_delay.3.gz
/usr/man/man3/pam_open_session.3.gz
/usr/man/man3/pam_setcred.3.gz
/usr/man/man3/pam_start.3.gz
/usr/man/man3/pam_strerror.3.gz
Peter
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.x,comp.os.linux.development.apps
Subject: Re: Bsd and Linux
Date: 23 Mar 2000 08:41:54 GMT
In comp.os.linux.development.apps Nate Eldredge <[EMAIL PROTECTED]> wrote:
: "Peter T. Breuer" <[EMAIL PROTECTED]> writes:
:> I am hardly likely to forget to configure a new shell, having gone to
:> the trouble of adding it!
: You'd be surprised. Adding a profile is not an obvious part of
: "configuration".
It is, to me! That's why I presumably added a new shell.
:> But yes, it;s robust. The consequences of
:> losing the config file are that restrictions are lifted. The
:> consequence of losing libpam stuff is that nobody can log in. I.e.
:> it does not fail safe. By design, I imagine, since the mentality
:> of the desiger seems to be that making it difficult to log in to
:> a system is good.
: It's a trade-off. Personally I would rather have nobody able to log
: in, than have logins unrestricted. The cost of the one is a bit of
This is great until your server suffers a power cut while reading libpam.so and
comes back up without it, and won't let you log in even if you are sitting next
to it!
: lost work and a couple commands typed by the admin; the cost of the
: other is a root compromise and an awful lot of admin work to re-secure
: it.
There is no compromise possible. I have all files scanned every day both
internally and externally (via NFS). All logs are sent to a remote
machine for scanning every hour. The filtered results are delivered by
mail to me personally. The only break in I have suffered was on a stock
solaris ultrasparc, via a warez kiddie using an ftp exploit. I saw it
within the day, and watched the antics for 3 days, before dropping him
in it.
: But really, this isn't an inherent disadvantage of libpam. How does
: the system "fail safe" if you lose /lib/libc.so? /bin/login?
Agreed. These are all pieces that are necessary. However they are substantially
independent. My login and sh are compiled statically, so I can login without libc.
: /etc/passwd? It's just another necessary piece. Arguably it's one
Losing /etc/passwd is a horror. That's essentiully what losing _any bit_ of pam amounts
to.
: too many, but there's nothing special about it.
:> : BTW, two config files that duplicate each others functionality is not
:> : "centralised control". It's a maze and tangle of loose ends.
:>
:> It most certainly is not. I have no trouble with two exactly similar files,
:> ad I only maintain two out of good nature.
: And what if instead of one or two shells, there were fifty?
There aren't.
: Also, configuring security limits in a shell profile is not
: necessarily safe, since the user may well be able to abort the profile
: before it finishes. (And a trap command at the top only makes the
: window smaller, it does not eliminate it.)
An aborted /etc/profile should result in an exit from the shell -. It
does here.
Peter
------------------------------
From: [EMAIL PROTECTED] (Stefan Ohlsson)
Crossposted-To: comp.os.ms-windows.nt.advocacy,comp.sys.amiga.advocacy
Subject: Re: A pox on the penguin? (Linux Virus Epidemic)
Reply-To: Stefan Ohlsson <[EMAIL PROTECTED]>
Date: 23 Mar 2000 09:53:17 +0100
The Ghost In The Machine wrote:
>>>It was a beautiful design, all around, for its time. Sigh. :-)
>>Still is :)
>
>Actually, there was one wart. A prioritized list was used for
>scheduling, which means that, if a lot of processes were running,
>the system had to do a bit of searching in order to insert a
>process in the proper place in the list. (Since no more than
>a couple dozen processes usually ran, this was probably an
>acceptable tradeoff as opposed to constructing something more
>complicated and space-hungry.)
>
I don't know exactly how processes are inserted, but I currently
have 96 processes lurking and I can't notice any slowness. On a
regular 68000 I maybe would though :)
>A derivative of this wart
>was that the scheduler didn't adjust priorities as processes
>waited in the queue, which means that a high-priority process
>could in fact lock out just about everyone else -- at least,
>until it had to wait for something.
>
That's right, AmigaOS is using static priorities. That has advantages
too, you can adjust the pri of a task and be certain that it always gets to
run before another with lower pri. That may be an advantage in those embedded
systems where the discussion started.
And in CSAA there have been comprehensive discussions about a program
called Executive that gives dynamic priorities to AmigaOS.
>The other flaw -- not really a wart, since the hardware at the
>time of the original design just wasn't available! -- is that
>it didn't do Virtual Memory Management (VMM) well. Of course,
>VMM didn't even exist back in '83 or so for consumer-level equipment.
>
There are things in it that makes VMM very hard to implement, like
shared memory and message passing using it. There are VMM-handlers
for Amigas with MMU though.
>But these are small flaws, considering that the alternative back
>then was the Dumb Operating System. :-) (And I suspect AROS will
>improve on these -- after all, it's only been what? 15 years
>or so? since the Amiga first came out; we've learned a lot
>about OO and computing complexity since then. I hope...)
>
So do I :)
/Stefan
--
[ Stefan Ohlsson ] · http://www.mds.mdh.se/~dal95son/ · [ ICQ# 17519554 ]
Ripley: These people are here to protect you. They are soldiers.
Newt: It won't make any difference.
/Aliens
------------------------------
From: George Marengo <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy,comp.sys.mac.advocacy
Subject: Re: Giving up on NT (Bob shows his lack of knowledge yet again)
Date: Thu, 23 Mar 2000 09:19:05 GMT
On Wed, 22 Mar 2000 20:50:43 GMT, [EMAIL PROTECTED] (JEDIDIAH)
wrote:
>On Wed, 22 Mar 2000 20:31:33 GMT, George Marengo <[EMAIL PROTECTED]> wrote:
>>On Wed, 22 Mar 2000 09:54:59 GMT, [EMAIL PROTECTED] (JEDIDIAH)
<snip>
>>I said it would have been financial suicide for the PSP _division_,
>>not the company, because I don't think they would have sold many
>>PC's if they decided that they would offer only OS/2 on those
>>machines.
>
> Why would offering another choice dissuade buyers? Perhaps
> FORCING them to have OS/2 preloaded might have been a
> problem but that's not what's under discussion.
So why didn't they simply offer OS/2 as the installed OS and have
Windows as an extra-cost option? It was the Better DOS than DOS
and Better Windows than Windows OS, right?
------------------------------
From: George Marengo <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy,comp.sys.mac.advocacy
Subject: Re: Giving up on NT (Bob shows his lack of knowledge yet again)
Date: Thu, 23 Mar 2000 09:20:29 GMT
On Wed, 22 Mar 2000 20:48:47 GMT, [EMAIL PROTECTED] (JEDIDIAH)
wrote:
>On Wed, 22 Mar 2000 20:27:20 GMT, George Marengo <[EMAIL PROTECTED]> wrote:
>>Sure, but if they had done that, they would NOT have had to pay any
>>licensing fees for Windows. Why didn't they just install OS/2 as a
>>preload and be done with Windows?
>
> The same fact that has hobbled anyone for the last 20 years,
> the fact that there's more to gaining utility out of an OS
> than just having the system software sitting on a disk.
>
> Everything else has to come along with it including driver
> support and 3rd party application support.
And thus my claim that it would have been financial suicide -- very
few people would have wanted "just having the system software
sitting on a disk"
------------------------------
From: "Erik Funkenbusch" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: Windows 2000: nothing worse
Date: Thu, 23 Mar 2000 03:42:35 -0600
Klaus-Georg Adams <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > They could have, but it would be expensive to do so and would have to be
> > done again when Merced hits. Why should they do it twice?
>
> The real question is why should anybody else migrate their stuff to
> $WINDOWS_VERSION_OF_THE_DAY if MS itself doesn't think it appropriate
> to get real work done. It is just as expensive to migrate for all
> those people to whom MS says Win 2000 is the best thing since sliced
> bread as for MS themselves.
How many people have an application as demanding as Hotmail? 30 million
user accounts.
Microsoft uses Windows 2000 to run www.microsoft.com and www.msn.com and
other sites. Hotmail is the only site they do not use it for, and that's
because they purchased it the way it is and have not yet migrated it for
what amounts to a myriad of potential reasons.
> Conclusion: Win 2000 is not up to the task. Wait for Win 2000 64
> Datacenter. If that's not good enough, wait for Win 2010 128bit TNG...
> If you want to get your work done _now_, use Unix, even if you have to
> customize your TCP/IP somewhat (whatever this means).
Who said anything about "big enough"? In order to process data for 30
million user accounts, you need hefty systems with hefty I/O requirements.
A 64 bit architecture for this is almost mandatory.
------------------------------
From: "Christopher Smith" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: Why did we even need NT in the first place?
Date: Thu, 23 Mar 2000 19:49:58 +1000
"Tim Kelley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Christopher Smith wrote:
> >
> > "Tim Kelley" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Christopher Smith wrote:
>
> > > If winnt was not hindered by having to be
> > > backward compatible with other windows apps (a purely economic
> > > focus on MS' part),
This is a somewhat worthless statement, as well, since every action
undertaken by a commercial company essentially has "a purely economic
focus".
> > Yes, I'm sure the idea of supporting their existing userbase never
entered
> > into the issue.
>
> that is correct. They had a poorly designed system, and made a
> concsious decision to stick with it and include much of it in
> NT. How many times do I have to say it? Or will you just keep
> saying "No it isn't"?
How long are you just going to keep saying "is too" ?
> Yes, I am saying that with NT they probably would've done better
> to break all compatibility start from scratch.
Then what would have been the reason to use NT ?
> At the time
> backwards compatibility wasn't nearly as big an issue as it is
> now, they had virtually no competition in '92. The problem with
> this is that the issue just gets worse and worse.
Backwards compatibility has *always* been the issue. A whole OS (Windows
9x) was created purely to pander to backwards compatibility.
Please show some examples or documentation about how NT's fundamental design
has been crippled by backwards compatibility.
> > > they could've used a sensible multi-user
> > > interface and filesystem standard, as unix has.
> >
> > Ahh, so it's the "it's not Unix so it's wrong" argument again ?
>
> Nope. I don't care if they did it the unix way or not.
Well you obviously do since they haven't and you're bitching about it.
> I'm
> using unix as an example of a well design multi-user system
> because it's the only one I'm familiar with. I'm sure there are
> others.
I'm sure there are to. NT is one.
> > > > "Like 9x" in what way, precisely ?
> > >
> > > you mean you can't tell?
> >
> > No. Perhaps in the great wisdom you believe you're blessed with you can
> > enlighten me ?
>
> OK. Set two computers up side by side, one with NT, and one with
> 9x. Then stare at them for a while. Get it?
What am I supposed to be looking for ?
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
