Linux-Misc Digest #663, Volume #27               Fri, 20 Apr 01 19:13:02 EDT

Contents:
  Re: swat and samba. (Mike Petersen)
  Re: Need help with core file generation (Juergen Heinzl)
  Re: book recommendation? ("Robert Wiegand")
  Re: DHCP and Road Runner blues (grooveman)
  Re: Which distro for 2.4.x ? ("Peter T. Breuer")
  Re: DHCP and Road Runner blues (Bit Twister)
  Re: sendmail :s ("Peter T. Breuer")
  Re: is user list accessable? ("Peter T. Breuer")
  Re: Which distro for 2.4.x ? ("Peter T. Breuer")
  Re: Compile errors for ltmodem RH7.0 ("Bob M.")
  Re: sendmail :s (John Todd)
  finding specific files. ("Joel")
  Re: is user list accessable? (Juergen Heinzl)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Mike Petersen)
Crossposted-To: alt.os.linux,comp.os.linux.setup
Subject: Re: swat and samba.
Date: Fri, 20 Apr 2001 21:50:16 GMT
Reply-To: [EMAIL PROTECTED]

Make sure you have smbd and nmbd starting, either manually or on
bootup (to configure on bootup add script to /etc/inet.d). 

Also do the same for apache.

Once you know that both samba and Apache are starting up add this to
your /etc/services file.

swat    901/tcp

Then add the following to your /etc/inet.conf file

swat    stream  tcp     nowait.400      root    /usr/sbin/tcpd
/usr/sbin/swat

After you do this swat should be back up and running.  Note that I
usually set-up Debian servers from source so this may or may not be
the correct places for swat configuration.


If you need a script to start/stop samba this is the one i use


#!/bin/sh
#
# Start/stops the Samba daemons (nmbd and smbd).
#

PATH=/usr/local/samba/:/usr/local/samba/bin:/sbin:/bin:/usr/sbin:/usr/bin

NMBDPID=/usr/local/samba/var/locks/nmbd.pid
SMBDPID=/usr/local/samba/var/locks/smbd.pid

# See if the daemons are there
test -x /usr/local/samba/bin/nmbd -a -x /usr/local/samba/bin/smbd ||
exit 0

case "$1" in
        start)
                echo -n "Starting Samba daemons:"

                echo -n " nmbd"
                start-stop-daemon --start --quiet --pidfile $NMBDPID
--exec /usr/local/samba/bin/nmbd -- -D

                echo -n " smbd"
                start-stop-daemon --start --quiet --pidfile $SMBDPID
--exec /usr/local/samba/bin/smbd -- -D

                echo "."
                ;;
        stop)
                echo -n "Stopping Samba daemons:"

                echo -n " nmbd"
                start-stop-daemon --stop --quiet --pidfile $NMBDPID
--exec /usr/local/samba/bin/nmbd -- -D

                echo -n " smbd"
                start-stop-daemon --stop --quiet --pidfile $SMBDPID
--exec /usr/local/samba/bin/smbd -- -D

                echo "."
                ;;
        reload)
                echo -n "Reloading /etc/samba/smb.conf (smbd only)"
                start-stop-daemon --stop --signal HUP --pidfile
/var/samba/smbd.pid --exec /usr/local/samba/bin/smbd -- -D

                echo "."
                ;;
        restart|force-reload)
                echo -n "Restarting Samba daemons:"

                echo -n " nmbd"
                start-stop-daemon --stop --quiet --pidfile $NMBDPID
--exec /usr/local/samba/bin/nmbd -- -D
                sleep 2
                start-stop-daemon --start --quiet --pidfile $NMBDPID
--exec /usr/local/samba/bin/nmbd -- -D

                echo -n " smbd"
                start-stop-daemon --stop --quiet --pidfile $SMBDPID
--exec /usr/local/samba/bin/smbd -- -D
                sleep 2
                start-stop-daemon --start --quiet --pidfile $SMBDPID
--exec /usr/local/samba/bin/smbd -- -D

                echo "."
                ;;
        *)
                echo "Usage: /etc/init.d/samba
{start|stop|reload|restart|force-reload}"
                exit 1
                ;;
esac

exit 0


------------------------------

From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Need help with core file generation
Date: Fri, 20 Apr 2001 21:56:25 GMT

In article <[EMAIL PROTECTED]>, Hsuan-Chung Lee wrote:
>Hi:
>
>While running Redhat Linux 6.2,  I was able to force tail to generate
>core by giving it a signal.  However, I was unable to do the same with
>vi.  Is there a system level way to force all programs to generate core
>files?
[-]

No - and an application can inhibit the generation of core
dumps, so it's not just a signal handling matter.

Ta',
Juergen

-- 
\ Real name     : Juergen Heinzl                \       no flames      /
 \ EMail Private : [EMAIL PROTECTED] \ send money instead /

------------------------------

From: "Robert Wiegand" <[EMAIL PROTECTED]>
Subject: Re: book recommendation?
Date: Fri, 20 Apr 2001 16:43:03 -0500

In article <9both4$hif$[EMAIL PROTECTED]>, "dmayo"
<[EMAIL PROTECTED]> wrote:

> NOW THE QUESTION IS:
> Could anyone recommend me a good book that will teach me things like: -
> how to modify and understand .conf files - how to install and uninstall
> packages - how to check on memory usage and needs - how to administer
> other users in my system (which is composed of my wife and myself...)
> - and more...

Take a look at:
http://www.linuxdoc.org/

-- 
Regards,
Bob Wiegand   [EMAIL PROTECTED]

------------------------------

From: grooveman <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux.x,alt.linux.redhat,alt.linux,alt.os.linux,comp.os.linux.networking,comp.os.linux.setup,comp.os.linux.x
Subject: Re: DHCP and Road Runner blues
Date: Fri, 20 Apr 2001 22:04:28 GMT

Sorry bit,

I posted the code outside this thread... but it is only a couple threads
away....

I tried this, and I still get nothing...

BTW:  How did you know it was nic-c54-102?

Also, doing ls -al /etc/sysconfig/network-scripts/ifcfg-eth0  simply tells me
the mode for that file.... unless I am missing something there....  Was that
a typo, or am I in err?


Thanks a lot for your help!


Chris

Bit Twister wrote:

> Did you
>
> On Thu, 19 Apr 2001 22:04:27 GMT, grooveman <[EMAIL PROTECTED]> wrote:
> >
> >I modified ifup and ifdown, basically by replacing the pump commands
> >with their dhcpcd equivalents.  Then, I wrote a script that loops the
> >ifup until it gets a lease.  I put the script at the end of rc.local,
> >rather than having eth0 come up at init level 3.  The net result is that
> >it runs through everything fine, and at the very last stage, tries to
> >bring up eth0 until it is successful.  It take about 10 times plus or
> >minus.
> >
>
> At the command line can you do
>           /sbin/dhcpcd -h "nic-c54-102" eth0
> and does
>          ls -al /etc/sysconfig/network-scripts/ifcfg-eth0
> show the time you did the dhcpcd command or does it time out?
>
> if you are truly getting 1 in 10 their server is flaky.
>
> post your dhcpcd code you put in rc.local


------------------------------

From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Which distro for 2.4.x ?
Date: Sat, 21 Apr 2001 00:05:01 +0200

Christian Rose <[EMAIL PROTECTED]> wrote:
> "Peter T. Breuer" wrote:
>> I don't mind also. But then I like writing and compiling my own executables
>> and writing and maintaining my own admin scripts. Must end-users don't.

> So you *do* compile your own programs after all. Then why should you
> move binaries around between distros?

Me? I'm not talking about me, by and large! What I do isn't what you
do, or what most people do. Most people plonk down binaries from
packages, without any finer comprehension other than that they are
"installing" something (they may well be destroying their system
instead!).

>> > Linux. And no point in having several distributions if they are allowed
>> Point? There is no point. This is a social and commercial phenomenon.

> And this social phenomenon wouldn't have existed in the first place if
> Linux was only one distribution. I like multiple distributions. Not
> because I use all of them (not even close) but because they help improve
> Linux and GNU as a whole.

And how does them being binary compatible or not impinge upon your
viewpoint?

>> > And if all Linux distributions should have to contain precisely the same
>> > software to guarantee binary compability, when and how should changes
>> 
>> Strawman. They don't have to contain the same software in order to
>> guarantee binary compatibility.

> Umm, yes. Did you suddenly forget about gcc, libraries, etc.?

No. I have many distros that don't have the same software and yet are
binary compatible. hence we deduce that distros don't need the same software
in order to be binary compatible. Please stick to ordinary socratean logic!

>> > So no point in getting the Red Hat 7 binary, no? Use the one that best
>> > fits with your platform. Can you give one specific example of
>> > binary-only software that is only available for Red Hat 7.x? I for sure
>> 
>> Dunno about RH 7, but I'm still running the NeXS spreadheet
>> (excel-alike) that I filched from RH 4.1 Professional deluxe in around
>> 1996. It's excellent. Much better than staroffice.

> I take that as a "no, I didn't find an example of binary-only software
> that is only available for Red Hat 7.x"... point proven.

I don't run RH7 and so I'm not looking. Point not proven. Your brand of
mislogic is beginning to slightly annoy me ... 

>> Teach 'em all to program and that'll be fine, eh? Heh.

> No, teach them to use a computer and how to install software by
> following instructions. That's vastly different from asking them to
> program.

Perhaps electric shocks from the keyboard until they get it right?

>> >> Nonsense. I had kernel 2.4 on my slackware 3.0 ages ago. And so did
>> >> slackware (and debian, and suse ..).
>> 
>> > Was kernel 2.4 installed with Slackware 3.0? Does SuSE use it by
>> 
>> Most certainly! I did it.

> But Slackware didn't. So what was your point? We were talking about
> Linux distributions using kernel 2.4 by default!

The point was what I said just after that sentence, and which you have
not accounted for. Having 2.4 on your distro is a five minute work
of installation, involving putting in new modutils and pppd, and
booting the kernel. If you also wanted to compile that kernel, you also
need new binutils. So don't make out that RH is achieving some lofty
pinnacle thereby. ANY distro can have kernel 2.4 in it, and all the
ones I have experience of have kernel 2.4 available in their most
current versions.

>> > default? Does Debian stable have it? I don't think so. What was your
>> > point?
>> 
>> That all these distros most current versions have the 2.4 kernel in
>> (yes, debian "stable" != debian most current). And secondly, as you
>> know, it would take five minutes to outfit any distro with it - witness
>> my s/w 3.0 plus new modutils and new pppd and new kernel (and new
>> binutils for luck).

> "Has it in" is vastly different from "uses it by default and is tested
> with it".

No it isn't, as I just said.

>       * SuSE 7.1 uses kernel 2.2.18 by default.

Not that I have a copy of the most recent 6 cds of Suse nearby, but
last time I looked, I am pretty sure I saw the 2.4 kernel tehere.

>       * Debian "most current" is not a released distribution, nor a
>         tested one.

It is and it is. Several debian distros exist at once. One of them
changes not at all, and is called "stable". One of them changes
continuously and is called "unstable", until it is stopped, and becomes
the "stable", while another takes up the reins and becomes the
"unstable". That's what happens with RH too, except that their
changes come as "errata" after a milestone, rather than "patches"
leading up to a milestone. The difference is in your perception.

>       * Slackware 3.0 most certainly does not use kernel 2.4; heck,

My copy does.

>         my copy of Slackware 7.0 has kernel 2.2.13!

Something bad about that? I like 2.2.15 better than 2.2.13, but both
are better than 2.2.18/19, which has such changes in the ext2 and fs
subsystems that I am unable to port e2compr forward to them. So I'm not
(using them). There are some minor patches that one can apply against
2.2.13 source to secure them and fix a network bug that can deadlock
(that was fixed in 2.2.18) but patrick compiled those kernels very
well as fas as I can see, and the binaries don't seem bad at all.

And slackware 7.1 is more recent than your copy.


> As for "it takes five minutes to outfit any distro with [kernel 2.4]" -
> your box must be pretty fast in compiling, and you must be very fast in
> verifying thet everything later on works correctly under all
> circumstances and hardware configurations...

Well, since you asked:

  -rw-r--r--    1 root       891734 Apr 16 18:11 vmlinuz-2.4.2-SMP
  -rw-r--r--    1 root       894650 Apr 16 19:04 vmlinuz-2.4.2-SMP-xfs
  -rw-r--r--    1 root       889364 Apr 18 02:05 vmlinuz-2.4.3-SMP
  -rw-r--r--    1 root       891087 Apr 18 02:14 vmlinuz-2.4.3-SMP-xfs
  -rw-r--r--    1 root       891205 Apr 18 02:22 vmlinuz-2.4.1-SMP
  -rw-r--r--    1 root       892263 Apr 18 02:24 vmlinuz-2.4.0-SMP-xfs
  -rw-r--r--    1 root       893155 Apr 18 03:16 vmlinuz-2.4.1-SMP-xfs

for a representative picture of how fast I can compile kernels (these
are patched with xfs 0.9 and 1.0, so you have to allow time for
me to patch and fix rejects too). And yes, I am fast at verifying
that all works well .. All kernels are in use in at least two machines
under varying circumstances day and night. And I can tell you that I
have been personallyusing 2.4.0 day and nght on THIS portable toshiba
with slackware 7.0 since, oh ... feb 11 at least.

  -rw-r--r--   1 root       756854 Feb 11 13:45 vmlinuz.900-SMP
  -rw-r--r--   1 root       761160 Mar  6 01:03 vmlinuz.900-SMP-xfs

>> >> > exclusively. So you know it works with and is properly tested with 2.4.
>> >>
>> >> You know no such thing.
>> 
>> > Thank you for telling me that I don't know. I sure appreciate your
>> > expert opinion on that.
>> 
>> It's derived from years of observation of RH, not of you.

> So how on earth are you able to tell me what I know and do not know?

Let's try the logic thing again, shall we? If you tell me you know that
white is black, then I can go ahead and tell you that you know no
such thing. Sure, you may believe it, but you don't know it, just
as you don't know that reindeer fly home for christmas, whatever you
think you may know.

>> So, tell me, have they got rid of the bug whereby if you tried to
>> unchoose gnome at install, you couldn't, because the installer can't
>> forget its existing dependencies? One goes round in circles trying
>> again and again to remove something else that pops up as a dependency
>> failure. (that was RH 6.1).

> Yes. It was fixed long ago. I believe it was fixed in 6.2.

Good, that's nice. And I suppose that you, as a beta tester, warned
them about that bug, but they somehow forgot

>> Or have you tried installing with a 128MB / partition, a 2GB /usr
>> partition, and whatever else? I couldn't despite the totals being
>> within spec, because the installer can't calculate WHERE the packages put
>> their stuff, and thinks it won't fit, when it will. (again 6.1 or
>> 6.2, I think).

> I have a 128 MB / and 2.6 GB /usr, close to your specs. Yes, it worked
> flawlessly with RH 6.2, 7.0 and 7.1 (all of them have been installed

Well it didn't with me. Perhaps you should measure the size of your
/bin /etc /sbin and /lib, /root partitions, add 10MB, then try
reinstalling with a / partition of that size? You may save RH an
embarrassing exhibition at the next "installfest". My impression is
that rpm simply does not have the info about what goes where, or
there is a bug in the rpm calculation.

> onto this machine).

>> And then there's the magificent error I get at every expert install of
>> redhat, where one has to step aside and create the /tmp/mnt/dev/*
>> oneself, just so that fdisk can access the specials for the device you
>> WILL create with it in the future. Clever idea that. Devices on demand
>> in /tmp, except it deosn't work.

> Never heard of that, and I don't use fdisk in the installer (using

Then I suggest you do, and you'll surely encounter it.

> diskdruid in the installer is so much faster), but it would surprise me
> if it wasn't fixed. Anyway, I hope you know that you can REPORT BUGS
> (http://bugzilla.redhat.com/bugzilla/). That also has the neat

And will I get an immediate comeback, like with debian? Plus
inclusion on the mailing circle of the developer group discussing the
bug and possible fixes, like with debian? No, I won't. Silence
is what you get out of RH. The most I ever got was a conversation
with eric troan in which we both concluded we were too busy to chase
the bug in which logrotate wouldn't work for anyone but root.

And have you got a version of ifconfig that doesn't have the alias bug
yet? You know .. ifconfig eth0:0 123.456.789.1, ifconfig eth0:0 down.
Oops. eth0 just disappeared too!

> sideeffect that you will know what happens with them and when they are
> fixed.

>> So who tested THOSE?

> I for sure didn't (my first Red Hat was 5.1 but I only started for real
> around 6.2 and 7.0), and neither did you, as you obviously didn't care
> in reporting any of this.

I started around 4.0. It was buggy as hell then, and it stayed that
way. I remember the wonderful time they issued a new kernel (2.0.0 ?)
and didn't change the scripts to match the new kernels netmask
conventions for 127.0.0.1. The result was that loopback never got
configured! Now it was pretty hard to miss that! Tested? No.

>> And as to RH 40, 4.1, 5.0, 5.1, ... Ithe errors were just as glaring.
>> If you're a beta tester, then please test something other than the
>> newbie-standard install path. I betcha it doesn't work.

> It does work. I know people who have *very* strange configurations, and
> yet it works. That's why there are betas of any operating system; so
> that people can try it out on strange configurations and with all
> possible strange hardware and software.

> Anyway, I hardly find this "old Red Hat releases had BUGS (oh the
> horror, we all know *no* other Linux distributions has bugs) so Red Hat
> must suck now and for all eternity" type of discussion meningful.

Why not? A track record of bugs like that leads one to suppose that it
will continue. It has so far! That's inductive logic for you! The
cleanest hypothesis that explains their track record is a fundamental
procedural malaise.

Putting it bluntly, they can't engineer (and I say that as a
professional engineer, ans professor of software and hardware
engineering with a fair track record in the literature on software
maintainence).  Their software is a stack of cards. Not that writing
systems software is easy, but they make it look hard.

As to why they can't engineeer, that's a business and organisational
question.

> Have you actually *tried* Red Hat 7.1? I mean, that would be far more

I have a test machine stuck in a corner somewhere. Uh, no, I'm sorry, I
lied. It's still at 7.0.

> relevant than complaining about versions released five years ago.

It's very relevant (and no, not five years, last year ..
that was essentially the last straw for me).

If you care to ask redhat to pass me a beta copy, I'll be happy to
find the first 5 bugs in the first five minutes of install/use.
But I'd probably feel inclined to charge them for the favour.

Peter

------------------------------

From: [EMAIL PROTECTED] (Bit Twister)
Crossposted-To: 
comp.os.linux.x,alt.linux.redhat,alt.linux,alt.os.linux,comp.os.linux.networking,comp.os.linux.setup,comp.os.linux.x
Subject: Re: DHCP and Road Runner blues
Reply-To: [EMAIL PROTECTED]
Date: Fri, 20 Apr 2001 22:26:19 GMT

On Fri, 20 Apr 2001 22:04:28 GMT, grooveman <[EMAIL PROTECTED]> wrote:
>Sorry bit,
>
>I posted the code outside this thread... but it is only a couple threads
>away....
>
>I tried this, and I still get nothing...
>
>BTW:  How did you know it was nic-c54-102?

@HOME has no clue about helping you hide from crackers.
They post your ip in the news header.

>Also, doing ls -al /etc/sysconfig/network-scripts/ifcfg-eth0  simply tells me
>the mode for that file.... unless I am missing something there....  Was that
>a typo, or am I in err?


        Auh, there was a malfunction between the keyboard and the chair,
        /etc/dhcpc/dhcpcd-eth0.info's  date stamp is the last time
        dhcpcd obtained the lease.

------------------------------

From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: sendmail :s
Date: Sat, 21 Apr 2001 00:18:42 +0200

blobbybirdman <[EMAIL PROTECTED]> wrote:
> can anyone tell me how to set up sendmail, cos everyone I ask seeks to
> hiss like a vampire confronted by a crucifix and then make their excuses

You don't have to do anything in particular. It should run out of the
box if you have anything like a normal setup.

> and run. I am running red hat 7.0 on a local university network. I have
> pine set up to read my mail, but I'll be jiggered if I can find out how
> to get the sendmail working.

What's the problem? Start sendmail -bd -q3m. Edit the sendmail.cf
file if you really need to.

Peter

------------------------------

From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: is user list accessable?
Date: Sat, 21 Apr 2001 00:16:33 +0200

Jeffrey J. Bacon <[EMAIL PROTECTED]> wrote:
> can I make /etc/passwd readbale only by root? or will this conflict with
> something else?

Everything else! Practically every process has to read passwd.

   oboe:/usr/oboe/ptb% strace -eopen sh -c 'echo foo > /tmp/foo'
   open("/etc/ld.so.cache", O_RDONLY)      = 3
   open("/lib/libtermcap.so.2", O_RDONLY)  = 3
   open("/lib/libc.so.5", O_RDONLY)        = 3
   open("/etc/passwd", O_RDONLY)           = 3
   open("/tmp/foo", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3


Peter

------------------------------

From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Which distro for 2.4.x ?
Date: Sat, 21 Apr 2001 00:13:50 +0200

Christian Rose <[EMAIL PROTECTED]> wrote:
> Have you actually *tried* Red Hat 7.1? I mean, that would be far more
> relevant than complaining about versions released five years ago.

Just seen a couple of threads further on ...

> Reece Robinson <[EMAIL PROTECTED]> writes:
> > Has anyone else noticed that Sun's JDK1.3 and 1.3.1 don't work properly
> > on RH 7.1??
> RedHat has, they tell this in the 7.1 release notes under heading
> "Known Issues / Trouble Spots".

Has mc stopped showing doubled entries on ftp://foo.bar/ connections yet?

Peter

------------------------------

Reply-To: "Bob M." <[EMAIL PROTECTED]>
From: "Bob M." <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.portable
Subject: Re: Compile errors for ltmodem RH7.0
Date: Fri, 20 Apr 2001 18:34:27 -0400

I had a similar problem (...should not use kernel headers...) with another
ltmodem package. Eventually I gave in and loaded (via RPM) the KERNEL
HEADERS package. Even though it seemed to have already been there, a fresh
load of it cleared up my two compile problems. After that, the "make
install" ran in a couple of seconds and the modem worked first time.

By the way, this was on a Dell Inspiron 8000 laptop with the ActionTec (aka
Lucent chip set) winmodem.

Also, I got the package from a Lucent site. There was one for kernel 2.2.16
and 2.2.16-22. I got them both, but the one that worked was 2.2.16, even
though the kernel was 2.2.16-22. You might have better luck with the .16
version. I think the file was called "linux595.zip".

Hope this helps. Bob M.

Anti-Spam feature: DO NOT HIT REPLY !
Address all replies to: k c single at snet dot net
by removing the spaces and inserting the
correct punctuation for a standard address.

============================================

J Sako <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm trying add in support for ltmodem.o for my T20, but am running into
> compile errors during the build_module step.  Below is the output from
> the command. I noticed that while I'm running a 2.2.16-22 kernel, the
> kernel-headers as shipped with RH7.0 are at 2.4...huh?  Could that be
> the problem?  Any thoughts or suggestions would be greatly appreciated.
> Thanks.
>
> JS
>
>
>
> /downloads/tmp/ltmodem-5.78e #./build_module
> gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
> -fomit-f
> rame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486
> -malign-loops
> =2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -DMODULE
> -DLT_VERSION=5.78e  -c
>  -o serial.a serial.c
> In file included from serial.c:131:
> /usr/include/linux/modversions.h:1:2: #error Modules should never use
> kernel-hea
> ders system headers,
> /usr/include/linux/modversions.h:2:2: #error but headers from an
> appropriate ker
> nel-source
> In file included from /usr/src/linux/include/linux/vmalloc.h:8,
>                  from /usr/src/linux/include/asm/io.h:103,
>                  from serial.c:172:
> /usr/src/linux/include/asm/pgtable.h: In function `get_pgd_slow':
> /usr/src/linux/include/asm/pgtable.h:409: `PAGE_OFFSET_RAW' undeclared
> (first us
> e in this function)
> /usr/src/linux/include/asm/pgtable.h:409: (Each undeclared identifier is
> reporte
> d only once
> /usr/src/linux/include/asm/pgtable.h:409: for each function it appears
> in.)
> /usr/src/linux/include/asm/pgtable.h: In function `pte_alloc_kernel':
> /usr/src/linux/include/asm/pgtable.h:498: `PAGE_OFFSET_RAW' undeclared
> (first us
> e in this function)
> /usr/src/linux/include/asm/pgtable.h:506: warning: control reaches end
> of non-vo
> id function
> /usr/src/linux/include/asm/pgtable.h: In function `pte_alloc':
> /usr/src/linux/include/asm/pgtable.h:516: `PAGE_OFFSET_RAW' undeclared
> (first us
> e in this function)
> In file included from serial.c:172:
> /usr/src/linux/include/asm/io.h: In function `virt_to_phys':
> /usr/src/linux/include/asm/io.h:116: `PAGE_OFFSET_RAW' undeclared (first
> use in
> this function)
> /usr/src/linux/include/asm/io.h:118: warning: control reaches end of
> non-void fu
> nction
> /usr/src/linux/include/asm/io.h: In function `phys_to_virt':
> /usr/src/linux/include/asm/io.h:125: `PAGE_OFFSET_RAW' undeclared (first
> use in
> this function)
> /usr/src/linux/include/asm/io.h:127: warning: control reaches end of
> non-void fu
> nction
> /usr/src/linux/include/asm/io.h: In function `check_signature':
> /usr/src/linux/include/asm/io.h:184: `PAGE_OFFSET_RAW' undeclared (first
> use in
> this function)
> {standard input}: Assembler messages:
> {standard input}:9: Warning: Ignoring changed section attributes for
> .modinfo
> make: *** [serial.a] Error 1
> ln: ./ltmodem.o: File exists
> ln: ./ltinst: File exists
> ln: ./ltuninst: File exists
> run ltinst to install the ltmodem driver
>



------------------------------

From: [EMAIL PROTECTED] (John Todd)
Subject: Re: sendmail :s
Date: 20 Apr 2001 22:14:41 GMT
Reply-To: [EMAIL PROTECTED]

On Fri, 20 Apr 2001 20:04:44 +0100, blobbybirdman 
<[EMAIL PROTECTED]> wrote:
>can anyone tell me how to set up sendmail, cos everyone I ask seeks to
>hiss like a vampire confronted by a crucifix and then make their excuses
>
>and run. I am running red hat 7.0 on a local university network. I have
>pine set up to read my mail, but I'll be jiggered if I can find out how
>to get the sendmail working.
>
>cheers
>Blobby
>


There is a script to help with this, filename is
install-sendmail-5.3.1.tar.gz   
search for it on Google.


-- 
_____________________

The lap of Linuxury
|<de in RH6.0

------------------------------

From: "Joel" <[EMAIL PROTECTED]>
Subject: finding specific files.
Date: Fri, 20 Apr 2001 17:50:10 -0500

Hi.  I'm reletively new to linux.  I have Debian GNU/Linux 2.2 i386
installed.  I've been trying to figure out how to find the path of files if
I only know the name of the file.  ex:  I want to find fil /*/netscape, how
do I do it?  I've experimented with using ls -R */netscape with no luck.
I've also tried using the "find */netscape".  I have read the man pages for
these two programs, but can't figure this out.. Thanks in advance.



------------------------------

From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: is user list accessable?
Date: Fri, 20 Apr 2001 23:05:03 GMT

In article <[EMAIL PROTECTED]>, Jeffrey J. Bacon wrote:
>Francis Litterio wrote:
>> 
>> "Jeffrey J. Bacon" <[EMAIL PROTECTED]> writes:
>> 
>> > is there a way for someone to get a list of user from my Linux box?
>> 
>> If you have adequate network security, not without logging in.
>> 
>> > what if they're logged in, can they get it then?
>> 
>> Yes, they can type "cat /etc/passwd" to see all userids.
[-]
Or they can just do a ls -l /home 8)
>
>can I make /etc/passwd readbale only by root? or will this conflict with
>something else?
[-]
If someone from the outside has come that far you're having
far more serious problems than spam.

Anyway, see rwho and rusers, too and as soon as a user from
you machine can send emails, use a browser or has access to
the USENET you're probably going to be out of luck, more or
less.

Using all of the above heavily for years now ... my spam rate
is pretty low. Just tell people *not* to bounce spam messages
and *not* to "unregister" and so on. You can even add filters
to some MTA's, so I'd not really worry.

Ta',
Juergen

-- 
\ Real name     : Juergen Heinzl                \       no flames      /
 \ EMail Private : [EMAIL PROTECTED] \ send money instead /

------------------------------


** 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 by posting to comp.os.linux.misc.

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-Misc Digest
******************************

Reply via email to