Menu
▾
▴
devil-linux-develop
|
From: Bruce S. <bw...@ar...> - 2003-11-02 20:33:09
|
I turned off grsecurity and selected XFS (mrproper, new lfssystem) This is on a different PC than the previous ntp abort: patching file arch/i386/kernel/vm86.c Hunk #8 succeeded at 748 (offset 3 lines). patching file arch/i386/defconfig patching file init/main.c Hunk #1 succeeded at 74 (offset 5 lines). Hunk #3 succeeded at 568 with fuzz 2 (offset 8 lines). patching file Makefile Hunk #1 succeeded at 57 (offset 3 lines). Hunk #2 FAILED at 133. Hunk #3 succeeded at 235 (offset 2 lines). Hunk #4 succeeded at 310 (offset 4 lines). 1 out of 4 hunks FAILED -- saving rejects to file Makefile.rej can't find file to patch at input line 42991 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** /usr/src/linux-2.4.20/./drivers/sgi/char/shmiq.c Fri Nov 29 01:53:14 2002 |--- ./drivers/sgi/char/shmiq.c Fri Nov 29 06:51:29 2002 -------------------------- File to patch: |
|
From: Heiko Z. <he...@zu...> - 2003-11-02 21:16:18
|
Hey, the XFS part is not maintained, since it's not working with grsecurity. you have to get the latest patches and drivers. cya Heiko Bruce Smith wrote: >I turned off grsecurity and selected XFS (mrproper, new lfssystem) >This is on a different PC than the previous ntp abort: > > >patching file arch/i386/kernel/vm86.c >Hunk #8 succeeded at 748 (offset 3 lines). >patching file arch/i386/defconfig >patching file init/main.c >Hunk #1 succeeded at 74 (offset 5 lines). >Hunk #3 succeeded at 568 with fuzz 2 (offset 8 lines). >patching file Makefile >Hunk #1 succeeded at 57 (offset 3 lines). >Hunk #2 FAILED at 133. >Hunk #3 succeeded at 235 (offset 2 lines). >Hunk #4 succeeded at 310 (offset 4 lines). >1 out of 4 hunks FAILED -- saving rejects to file Makefile.rej >can't find file to patch at input line 42991 >Perhaps you used the wrong -p or --strip option? >The text leading up to this was: >-------------------------- >|*** /usr/src/linux-2.4.20/./drivers/sgi/char/shmiq.c Fri Nov 29 >01:53:14 2002 >|--- ./drivers/sgi/char/shmiq.c Fri Nov 29 06:51:29 2002 >-------------------------- >File to patch: > > |
|
From: Bruce S. <bw...@ar...> - 2003-11-03 00:55:17
|
> the XFS part is not maintained, since it's not working with grsecurity. > you have to get the latest patches and drivers. Do we support turning off grsecurity? I turned off grsecurity in menuconfig, did NOT select XFS and got the same thing. grsecurity keeps killing processes on my server, so I need to get rid of it. (or learn it, but turning it off sounds easier) :-) > >I turned off grsecurity and selected XFS (mrproper, new lfssystem) > >This is on a different PC than the previous ntp abort: > > > > > >patching file arch/i386/kernel/vm86.c > >Hunk #8 succeeded at 748 (offset 3 lines). > >patching file arch/i386/defconfig > >patching file init/main.c > >Hunk #1 succeeded at 74 (offset 5 lines). > >Hunk #3 succeeded at 568 with fuzz 2 (offset 8 lines). > >patching file Makefile > >Hunk #1 succeeded at 57 (offset 3 lines). > >Hunk #2 FAILED at 133. > >Hunk #3 succeeded at 235 (offset 2 lines). > >Hunk #4 succeeded at 310 (offset 4 lines). > >1 out of 4 hunks FAILED -- saving rejects to file Makefile.rej > >can't find file to patch at input line 42991 > >Perhaps you used the wrong -p or --strip option? > >The text leading up to this was: > >-------------------------- > >|*** /usr/src/linux-2.4.20/./drivers/sgi/char/shmiq.c Fri Nov 29 > >01:53:14 2002 > >|--- ./drivers/sgi/char/shmiq.c Fri Nov 29 06:51:29 2002 > >-------------------------- > >File to patch: > > |
|
From: Heiko Z. <he...@zu...> - 2003-11-03 01:10:17
|
Bruce Smith wrote: >>the XFS part is not maintained, since it's not working with grsecurity. >>you have to get the latest patches and drivers. >> >> > >Do we support turning off grsecurity? I turned off grsecurity in >menuconfig, did NOT select XFS and got the same thing. > > That should work fine.... And yes we support turning of grsecurity, we need to have this working. Is it possible that you had XFS leftovers from your last try ? What are the abort messages ? >grsecurity keeps killing processes on my server, so I need to get rid >of it. (or learn it, but turning it off sounds easier) :-) > > What are the messages ? Did you ask for help on the grsecurity forum ? cya Heiko |
|
From: Bruce S. <bw...@ar...> - 2003-11-03 01:17:54
|
> >>the XFS part is not maintained, since it's not working with grsecurity. > >>you have to get the latest patches and drivers. > > > >Do we support turning off grsecurity? I turned off grsecurity in > >menuconfig, did NOT select XFS and got the same thing. > > > That should work fine.... > And yes we support turning of grsecurity, we need to have this working. > Is it possible that you had XFS leftovers from your last try ? No, I checked. I grep'ed for XFS in .config and it was set to "n". > What are the abort messages ? They are scrolled off my screen now, but it was real similar with the kernel patches screwing up and hanging waiting for input. > >grsecurity keeps killing processes on my server, so I need to get rid > >of it. (or learn it, but turning it off sounds easier) :-) > > > What are the messages ? grsec: signal 6 sent to (thttpd:646) UID(65534) EUID(65534), parent (init:1) UID(0) EUID(0) I have no idea why it's doing that. There have been other messages about squid processes too. > Did you ask for help on the grsecurity forum ? No, I haven't checked into it yet. I thought it would be easier to turn off grsecurity since this box is behind a firewall anyway. Would NOT running /etc/init.d/grsecurity accomplish the same thing? - BS |
|
From: Heiko Z. <he...@zu...> - 2003-11-03 01:41:16
|
Bruce Smith wrote: >>>>the XFS part is not maintained, since it's not working with grsecurity. >>>>you have to get the latest patches and drivers. >>>> >>>> >>>Do we support turning off grsecurity? I turned off grsecurity in >>>menuconfig, did NOT select XFS and got the same thing. >>> >>> >>> >>That should work fine.... >>And yes we support turning of grsecurity, we need to have this working. >>Is it possible that you had XFS leftovers from your last try ? >> >> > >No, I checked. I grep'ed for XFS in .config and it was set to "n". > > The problem is, it could have messed up your kernel sources. Try again with a clean system, before you do anything. >>What are the abort messages ? >> >> > >They are scrolled off my screen now, but it was real similar with the >kernel patches screwing up and hanging waiting for input. > > As I said, try again with a fresh system. >>>grsecurity keeps killing processes on my server, so I need to get rid >>>of it. (or learn it, but turning it off sounds easier) :-) >>> >>> >>> >>What are the messages ? >> >> > >grsec: signal 6 sent to (thttpd:646) UID(65534) EUID(65534), parent (init:1) UID(0) EUID(0) > >I have no idea why it's doing that. >There have been other messages about squid processes too. > > What grsecurity does in this case, is loggin that something (init ?) send the signal 6 to thttpd. Do you have enough RAM ? I would try to get it running, since grsecurity improves the overal system security alot. Thttpd works fine for me, so it would be interesting to find out what's wrong. >>Did you ask for help on the grsecurity forum ? >> >> > >No, I haven't checked into it yet. I thought it would be easier to >turn off grsecurity since this box is behind a firewall anyway. > >Would NOT running /etc/init.d/grsecurity accomplish the same thing? > > You can try to set everything in /etc/sysconfig/grsecurity.proc to 0 and see if it behaves different. cya Heiko |
|
From: Bruce S. <bw...@ar...> - 2003-11-03 01:52:06
|
> >grsec: signal 6 sent to (thttpd:646) UID(65534) EUID(65534), parent (init:1) UID(0) EUID(0)
> >
> >I have no idea why it's doing that.
> >There have been other messages about squid processes too.
> >
> What grsecurity does in this case, is loggin that something (init ?)
> send the signal 6 to thttpd.
> Do you have enough RAM ?
I think so... :-)
# free
total used free shared buffers
cached
Mem: 774252 127792 646460 0 68980
23592
-/+ buffers/cache: 35220 739032
Swap: 1048568 0 1048568
> I would try to get it running, since grsecurity improves the overal
> system security alot.
>
> Thttpd works fine for me, so it would be interesting to find out what's
> wrong.
Yeah. I'm more interested in the squid messages.
I can live without thttpd on this box.
> >Would NOT running /etc/init.d/grsecurity accomplish the same thing?
> >
> You can try to set everything in /etc/sysconfig/grsecurity.proc to 0 and
> see if it behaves different.
I don't see any limits on memory in that file, and I haven't been able
to find any documentation on grsecurity yet ...
- BS
|
|
From: Heiko Z. <he...@zu...> - 2003-11-03 02:11:17
|
Bruce Smith wrote: >>>grsec: signal 6 sent to (thttpd:646) UID(65534) EUID(65534), parent (init:1) UID(0) EUID(0) >>> >>>I have no idea why it's doing that. >>>There have been other messages about squid processes too. >>> >>> >>> >>What grsecurity does in this case, is loggin that something (init ?) >>send the signal 6 to thttpd. >>Do you have enough RAM ? >> >> > >I think so... :-) > ># free > total used free shared buffers >cached >Mem: 774252 127792 646460 0 68980 >23592 >-/+ buffers/cache: 35220 739032 >Swap: 1048568 0 1048568 > Oh yes, that looks like enough memory. >>I would try to get it running, since grsecurity improves the overal >>system security alot. >> >>Thttpd works fine for me, so it would be interesting to find out what's >>wrong. >> >> > >Yeah. I'm more interested in the squid messages. >I can live without thttpd on this box. > > The problem could be the same cause. >>>Would NOT running /etc/init.d/grsecurity accomplish the same thing? >>> >>> >>> >>You can try to set everything in /etc/sysconfig/grsecurity.proc to 0 and >>see if it behaves different. >> >> > >I don't see any limits on memory in that file, and I haven't been able >to find any documentation on grsecurity yet ... > > Just set everything to 0 and see if it changes something. That's the way I do it. When it works after that, you have to find out which of the parameters causes the problem. cya Heiko |
|
From: Bruce S. <br...@ar...> - 2003-11-03 01:42:32
|
> > >grsecurity keeps killing processes on my server, so I need to get rid > > >of it. (or learn it, but turning it off sounds easier) :-) > > > > > What are the messages ? > > grsec: signal 6 sent to (thttpd:646) UID(65534) EUID(65534), parent (init:1) UID(0) EUID(0) Here's the squid messages: grsec: From 172.16.2.1: signal 6 sent to (squid:1043) UID(0) EUID(0), parent (squid:1039) UID(0) EUID(0) grsec: From 172.16.2.1: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (squid:1043) UID(0) EUID(0), parent (squid:1039) UID(0) EUID(0) - BS |
|
From: Heiko Z. <he...@zu...> - 2003-11-03 01:56:53
|
Bruce Smith wrote: >>>>grsecurity keeps killing processes on my server, so I need to get rid >>>>of it. (or learn it, but turning it off sounds easier) :-) >>>> >>>> >>>> >>>What are the messages ? >>> >>> >>grsec: signal 6 sent to (thttpd:646) UID(65534) EUID(65534), parent (init:1) UID(0) EUID(0) >> >> > >Here's the squid messages: > >grsec: From 172.16.2.1: signal 6 sent to (squid:1043) UID(0) EUID(0), parent (squid:1039) UID(0) EUID(0) > It's the same as thttpd. What the heck is signal 6 ? Ok I checked and it's SIGABRT (abort). Any C developers here who know what causes it? >grsec: From 172.16.2.1: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (squid:1043) UID(0) EUID(0), parent (squid:1039) UID(0) EUID(0) > > That means Squid coredumped. There could be a problem in your configuration file. cya Heiko |
