[cobalt-developers] Re: (OT) SPARCRaQ (cobalt-developers digest, Vol 1 #1393)

[System_FS <cobalt.lists@xxxxxxxxxxxxxxxxxxxxx>]

On Sun, Mar 24, 2002 at 03:16:31AM -0800, cobalt-developers-request@xxxxxxxxxxxxxxx wrote:
> From: "E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>
> I like the BSD feel of Slackware.

try
apt-get install file-rc
on debian.
It is not exactly a DSD-like rc system, but:
Description: Alternative boot mechanism using a single configuration file
 This package provides an alternative mechanism to boot the system, to
 shut it down and to change runlevels.  The /etc/rc?.d/* links will be
 converted into one single configuration file /etc/runlevel.conf
 instead, which is easier to administrate than symlinks, and is also
 more flexible.
 .
 The package will automatically convert your existing symlinks into
 the file method on installation, and convert the file back into
 symlinks on removal. Both mechanisms are compatible through
 /etc/init.d/rc, /etc/init.d/rcS, /usr/sbin/update-rc.d, and
 /usr/sbin/invoke-rc.d scripts.
		       
> But this does not change how
> the individual packages are rather out of sync with one another.

debian release a stable distribution only when the packages fit
toghether quite well (but this means that debian does not put in
stable releases the newest versions; even the security upgrades
are minimal patches to old versions)

> > true, but there exists sash busybox-static e2fsck-static ...
> Yes.  And, as much as I hate to display laziness... things like
> that should be part of the default install.

I never do default installs. With debian is easy in one of 3 ways:
(A) use an already existing linux installation and use debootstrap
    to start the install of debian on another disk (Slackware also 
    permits something like that with a script by Robotti, once I 
    installed Slak 8 on a 2nd HD from a debian machine. Theoretically
    also rpm permits to install witha a "base" different from /
    but in pratice things are not so easy)
(B) start the normal installation, but when I am at the final step
    I abruptly exit dselect and from the command line I apt-get
    install $what_I_want (apt-get automaticaly resolves dependencies)
(C) I manually (from a rescue floppy from one of the many mini-distros) 
    untar the base.tar.gz (after fdisk, mke2fs or whatever, mkswap, mount 
    partitions) and configure something in /mnt/etc and then 
    chroot /mnt /bin/bash 
    apt-get install $whatever_I_need 
    Finally install and configure the grub (or whathever) boot loader
    and "unplug" a file which debian use to avoid aborted installations.

> think that all fs should be mounted _sync_ by default

often a good idea on ext2, but we will see the newer (or linux ports
of older) journaled filesystems.

> When
> v1.2.3 of package A requires libwhatever.so.1.3.6 or newer, which
> requires libsomethingelse.so.2.0.9 or newer, but v2.0.4 of pkg B
> doesn't work right with libwhatever.so.1.3.4 or later...

this mean that you are not using apt-get (or dselect) to automatically
reseolve the dependencies. There exists a port by Conectiva of
apt-get to .rpm basesd dirtibutions (and that would be a good thing
to use on Cobalts, if possible ...) but apt-get can give good results
only with well packaged software (and unforunately there are many
not so good .rpm on the net and there are few apt repositories for
.rpm ; howevwe Conectiva is RH 6.2 based and uses apt-get on .rpm ...)

> are lower and less stressful under BSD. :-)

I agree completely if you compare FreeBSD with Slack or RH, Cobalt, 
Mandrake ... But not if the comaration is between debian and OpenBSD
(unless OpenBSD is only a stipped down firewall).
 
> > which, by *hardware* design, can be declared non-executable
> > (There are *software* patches for Linux to try that, see for example
> > the grsecurity.net project, and to use some kind of mandatory
> 
> IIRC, SolarDesigner released such a patch.

Not completely. It only makes more painful to exploit buffer overflows
but if you see grsecurity the PAX method seems to be better (and sloooower)
Moreover there exists also libsafe and stackguard in userspace
(I recently have seen a review of Cobalt Cube that said ... well what
you can immagine about the security of the product. Among other things
the review said that, being without libc5 software, Cobalt should have
installed libsafe)

> was merely explaining why I think that BSD is _better_ overall
> than GNU/Linux.

this is a reasonable opinion.

> From: Jeff Lasman <jblists@xxxxxxxxxxxxx>
> Date: Sun, 24 Mar 2002 09:29:56 -0800
> I admit I've never tried Debian.  Perhaps I will for a system I want to
> put into production in another week or so.  What's the BEST place to
> download ISOs?

i can not say what is the best way for you, but
http://www.debian.org/CD/
ha useful hints

> If they don't support my NIC (so far only RedHat >= 7.1
> does of all I've tried) will it be a real pain?

well, it suffices to use a kenlel that supports your card :-)
You can recompile the kernel o use a RH or whatever precompiled 
kernel. If you want to use a 2.4 kernel on debian potato be sure to
add the line
deb http://www.fs.tum.de/~bunk/debian potato main
to /etc/apt/sources.list and run 
apt-get update ; apt-get -u dist-upgrade
before using a 2.4 kernel

> I presume I won't have to recompile the kernel, but only build and rename
> a module? 

it depends on the module which is needed and the kernel symbols which
it needs

> Swapping the NIC isn't the option; it's built-on to the
> slotless motherboard <frown>.

well, you can add a supported card at lest during the installation
or try to use a plip o even slow serial network, if you do not want
to download the above A.Bunk packages for 2.4 kernels on another machine
and the move by floppy, zip, whathever on the debian machine
 
> I suppose I'll have to relearn a bit... is there a good Debian book you
> can recommend?

A book? Well I think you ask for an english language book, and
then I cannot help (beside saing http://www.debian.org/doc/books
http://www.debian.org/doc/manuals and /usr/doc on any debian machine. 
Yes, there is much more /usr/doc in debian than in RH). 
But since you already know well linux I think that 
http://qref.sourceforge.net 
will suffice. On the contrary for true newbies there is
http://newbiedoc.sourceforge.net

> I'd LOVE to
> use all statically-linked software; drive-space is cheap.

All? Well, bear in mind that with all statically linked software
you no more do have shared memory between programs and need much more
ram also (only load on demand saves some memory)
 
> beginner wouldn't be up to this skill level (or even this level in terms
> of thinking it out, if s/he came from a Windows background) for a few
> years.

you are right.

> > Y regret very much that Cobalt/Sun does not use the rpm porting
> > of apt-get for software upgrades.
> It makes a lot of sense for any Red Hat-based linux distribution to use
> RPM.

Conectiva uses apt-get to install .rpm packages that you manually install
with rpm (more or less like debian uses apt-get to install .deb packages 
that dpkg manually installs). But apt-get automatically resolves the
dependencies.
See apt+rpm HOWTO. http://bazar.conectiva.com.br/~godoy/apt-howto/
	        
> From: "E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>
> It would be nice if Linux had (or maybe they do, and I'm behind
> on things) something a la "sysctl -w kern.securelevel=xxx" to
> disable module loading.

lcap shoud do that on unpatched linux kernels:

Description: Removes 'capabilities' in the kernel, making the system more secure.
 Capabilities are a form of kernel-based access control. This program
 provides a user-friendlier way than setting proc/sys/kernel/cap-bound by hand
 to remove capabilities from your Linux kernel.
 .
 For example, you can remove the capability to load kernel modules by executing  
 'lcap CAP_SYS_MODULE' as root. Then no one, not even root, can load modules
 into your kernel. This can be useful for tightening the security of your
 Linux machines.
		     
But linux "capabilities" on unpatched linux kernels (>= 2.2.x)
seem to be not so good; 2.0 kernels probabily had a better
"emulation" of bsd securelevels

> I'm eager to see the results of the FreeBSD and Linux hardening
> projects that are underway.

me too.

But now we are far far away in the offtopic road ...