* checkpolicy and login names
From: david caplan @ 2002-09-24 14:32 UTC (permalink / raw)
To: selinux
In-Reply-To: <001001c263cc$de4ef570$6600a8c0@columbia.tresys.com>
We just ran across the case where we were trying to add a login name with a
'.' in it. When we tried to add the user to the policy, checkpolicy choked
on the '.' in the id. The parser expects an Identifier, which is defined to
be a letter followed by a combination of letter|digit|_ of any length.
Is there a compelling reason that this definition can't be changed? I'm not
sure if changing it would cause problems elsewhere in the policy mechanism.
There don't appear to be problems with using '.'s and '-'s in login names as
far as RedHat/Linux is concerned. I can't find any "standard" definition for
what are valid characters in a login name. Some applications, such as ps,
that have problems with the characters just use the uid instead. Others,
such as sendmail/pop and ssh, don't have a problem (at least in the versions
we're using).
david
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [LARTC] HTB
From: Rimas @ 2002-09-24 14:30 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-101661742904753@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 265 bytes --]
Thank you guys
Rimas
----- Original Message -----
From: Rimas
To: lartc@mailman.ds9a.nl
Sent: Tuesday, September 24, 2002 3:12 PM
Subject: [LARTC] HTB
Hi guys,
How to put HTB in to 2.4 kernel?
Thanks in advance
Rimas
[-- Attachment #2: Type: text/html, Size: 1682 bytes --]
^ permalink raw reply
* Re: SCSI woes (followup)
From: James Bottomley @ 2002-09-24 14:29 UTC (permalink / raw)
To: Russell King; +Cc: linux-scsi
In-Reply-To: <20020924145852.A28042@flint.arm.linux.org.uk>
rmk@arm.linux.org.uk said:
> I think it is misplaced. It locks the doors of devices that aren't
> even in use, which is just plain stupid.
A better fix is probably to implement a flag to say whether the door should be
locked or not.
The whole lock door before a command goes down philosophy looks slightly wrong
to me. I can see we want to lock the door for a mounted device and other
conditions, but locking the door just to send down a test unit ready or
inquiry doesn't seem correct.
Door locking is very similar to reservation maintenance. Perhaps adding
kernel code to maintain certain persistent but fragile states of the device
might be in order.
> Incidentally, I've found another weirdness in the code. We decide
> that we need to lock the door based on the "was_reset" flag, which we
> clear. However, st.c uses "was_reset" to decide whether to suspend
> operations (due to a bus reset). The two uses of this flag seem to
> conflict each other. How can we guarantee that st.c will see
> was_reset set if the request function clears it? st.c appears to use
> scsi_request_fn, so I guess there's a conflict of use there.
The code is riddled with these. Reset handling was really just bolted on to
the code as an afterthought.
James
^ permalink raw reply
* Re: USB Audio/Midiman - partial success
From: Takashi Iwai @ 2002-09-24 14:27 UTC (permalink / raw)
To: Pikus, Fedor; +Cc: Clemens Ladisch, alsa-devel
In-Reply-To: <Pine.LNX.4.31.0209232104140.18815-100000@lorien.wv.mentorg.com>
At Mon, 23 Sep 2002 21:14:36 -0700 (PDT),
Fedor G. Pikus <fedorp@wv.mentorg.com> wrote:
>
> On Mon, 23 Sep 2002, Clemens Ladisch wrote:
> > Fedor G. Pikus wrote:
> > > On Fri, 20 Sep 2002, Clemens Ladisch wrote:
> > >
> > > > case EXPIRED:
> > > > snd_printd("capture read error (DMA or IRQ trouble?)\n");
> > > > err = -EIO;
> > > >
> > > > Are you _really_ sure you have recompiled the entire alsa-driver package
> > > > with debug output, installed it correctly, and there's nothing in the log?
> > >
> > > kernel: ALSA ../alsa-kernel/core/pcm_lib.c:2212: EXPIRED in snd_pcm_lib_read1 ...
> >
> > The "capture read error" message should have been printed.
> > I guess debug output isn't really enabled for your ALSA core.
> I also thought so when I found that snd_printd. I use cvscompile which
> does add --with-debug-full to configure (and I tried running configure manually
> with this switch), --with-debug=full must not be working (I noticed earlier
> "full" does not generate the messages which are generated by "detect", so
> I'm not sure what "full" actually does).
well, snd_printdd() is activated only when --with-debug=detect is
used. but snd_printd() is activated even with --with-debug=full.
yeah, this debug option looks confusing. everybody would think that
full is full, but not fulfilled in reality :)
> > > when everything works ok it gets interrupted but when I'm trying to record
> > > at 96000 it does not. Where do I look now?
> >
> > In theory, snd_complete_urb is called when some data has been received
> > from the device, and this function calls retire_capture_urb. Please check
> > whether those functions are really called.
> They do get called, it goes like this:
> pcm_lib.c:2168 unlocked IRQ, waiting for 10 seconds
> snd_complete_urb called
> retire_capture_urb called
> retire_capture_urb done
> snd_complete_urb exits (by exiting through the bottom, never through return)
> ... repeat about 740 times the above 4 lines ...
> pcm_lib.c:2170 timed out after 10 seconds
does it means that complete is called _after_ the 10-sec-wait message?
could you tell me the function (line) corresponding to the original
source (the line is shifted so i cannot see where it is).
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply
* ascii code
From: Oana Tudor @ 2002-09-24 14:23 UTC (permalink / raw)
To: linux-newbie
Hi everybody,
I often use characters like â, à, ç and so on... I know how to make them in
Windows, using ALT+131, ALT+133, ALT+135 and so on... but when I try doing
this in Linux, it woun't work. Does anybody know how to make them without
installing special word procesors? I know that my question is trivial... but
I've been searching the internet with no luck.
Thanks a lot,
-oana
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [LARTC] HTB
From: Esteban Maringolo @ 2002-09-24 14:23 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-101661742904753@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
On Tue, 2002-09-24 at 11:12, Rimas wrote:
> Hi guys,
>
> How to put HTB in to 2.4 kernel?
Compile kernel 2.4.20 with HTB support.
Or else get kernel patches for 2.4.x (or 2.2.x) from devik's homepage.
--
Esteban A. Maringolo
Secont, Comunicaciones Digitales
Buenos Aires, Argentina
Tel: +54 (11) 4551-2455
http://www.secont.com.ar/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: Testing: NVidia closed driver fails.
From: Arnaud Fevrier @ 2002-09-24 14:22 UTC (permalink / raw)
To: P. Christeas; +Cc: Grover, Andrew, acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <200209221329.g8MDTL009929-a1J+ToZc0kR3t0M9ZKkFCQ@public.gmane.org>
Hi,
I have a fujitsu-Siemens CelsiusH which comes with a nvidia card. The
nvidia driver (1.0-2960) shares it interupts with the allegro sound
card.
I compiled the kernel 20-pre7 acpi 2002 09 18, and it boots fine.
I cannot run the make xconfig, and I had to set the SMP. It did not
compile for a uniprocessor.
A lot of acpi features work fine, but I cannot sleep or hibernate the
laptop.
Sincerly,
--
Arnaud Février
fevrier-94MxA55sdNz4HDTGivPSy1aPQRlvutdw@public.gmane.org
+33 () 491 177 926
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply
* Re: [LARTC] HTB
From: Marc-Christian Petersen @ 2002-09-24 14:17 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-101661742904753@msgid-missing>
On Tuesday 24 September 2002 16:12, Rimas wrote:
Hi Rimas,
> How to put HTB in to 2.4 kernel?
patching? :)
If you wanna try 3.6 code, download the tgz, untargzip it (tar xzpf) and
you'll see a diff/patch. Just "patch -p1 --dry-run < patchname" and see if it
succeed, if, leave out --dry-run, if not, fix the errors. If you have
questions when errors occur, don't hesitate to ask.
for HTB2 code, just download the patch and follow the same as above (patch -p1
...)
http://luxik.cdi.cz/~devik/qos/htb/
--
Kind regards
Marc-Christian Petersen
http://sourceforge.net/projects/wolk
PGP/GnuPG Key: 1024D/569DE2E3DB441A16
Fingerprint: 3469 0CF8 CA7E 0042 7824 080A 569D E2E3 DB44 1A16
Key available at www.keyserver.net. Encrypted e-mail preferred.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [ANNOUNCE] Native POSIX Thread Library 0.1
From: Michael Sinz @ 2002-09-24 14:20 UTC (permalink / raw)
To: Peter Svensson
Cc: Bill Huey (Hui), Peter Waechtler, linux-kernel, ingo Molnar
In-Reply-To: <Pine.LNX.4.44.0209241537340.2383-100000@cheetah.psv.nu>
Peter Svensson wrote:
> On Tue, 24 Sep 2002, Michael Sinz wrote:
>
>
>>The problem was very quickly noticed as other students quickly learned
>>how to make use of such "solutions" to their performance wants. We
>>relatively quickly had to add process level accounting of thread CPU
>>usage such that any thread in a process counted to that process's
>>CPU usage/timeslice/etc. It basically made the scheduler into a
>>2-stage device - much like user threads but with the kernel doing
>>the work and all of the benefits of kernel threads. (And did not
>>require any code recompile other than those people who were doing
>>the many-threads CPU hog type of thing ended up having to revert as
>>it was now slower than the single thread-per-CPU code...)
>
>
> Then you can just as well use fork(2) and split into processes with the
> same result. The solution is not thread specific, it is resource limits
> and/or per user cpu accounting.
I understand that point - but the basic question is if you schedule
based on the process or based on the thread. In an interactive multi-
user system, you may even want to back out to the user level. (Thus
no user can hog the system by doing many things). But that is usually
not the target of Linux systems (yet?)
The problem then is the inter-process communications. (At least on
that system - Linux has many better solutions) That system did not
have shared memory and thus the coordination between processes was
difficult at best.
> Several raytracers can (could?) split the workload into multiple
> processes, some being started on other computers over rsh or similar.
And they exist - but the I/O overhead makes it "not a win" on a
single machine. (It hurts too much)
--
Michael Sinz -- Director, Systems Engineering -- Worldgate Communications
A master's secrets are only as good as
the master's ability to explain them to others.
^ permalink raw reply
* Re: [parisc-linux] Help wanted: XF86Config (B2600)
From: Thibaut VARENE @ 2002-09-24 14:12 UTC (permalink / raw)
To: joachim.weller; +Cc: parisc-linux
In-Reply-To: <OF16A59BB3.066D8ECC-ONC1256C3E.004A35AA@diamond.philips.com>
joachim.weller@philips.com wrote:
>
> Merci beacoup Thibault,
>
> > it's a FXE card, unsupported.
> > Only Vis-EG are.
> > Support for these cards is planned to be worked on ;)
>
> Would it be possible to plug in a standard PC PCI Grafics card, like
> lets say
> a vanilla matrox mgag550 and use that driver ?
>
IIRC, some are supported (weren't we talking about Voodoo2 recently ? :)
You should take a look at the m-l archive:
http://www.parisc-linux.org/mailing-lists/
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/
^ permalink raw reply
* [LARTC] HTB
From: Rimas @ 2002-09-24 14:12 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-101661742904753@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
Hi guys,
How to put HTB in to 2.4 kernel?
Thanks in advance
Rimas
[-- Attachment #2: Type: text/html, Size: 757 bytes --]
^ permalink raw reply
* [LARTC] HTB
From: Rimas @ 2002-09-24 14:12 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-101661742904753@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
Hi guys,
How to put HTB in to 2.4 kernel?
Thanks in advance
Rimas
[-- Attachment #2: Type: text/html, Size: 757 bytes --]
^ permalink raw reply
* RE: Checkpoint VPN through Iptables
From: Preston Wade @ 2002-09-24 14:12 UTC (permalink / raw)
To: 'netfilter@lists.netfilter.org'
VPN's usually use some IP protocols that firewalls don't pass by default.
You probably want to read through the VPN-Masquerade-HOWTO.
http://www.linux.org/docs/ldp/howto/VPN-Masquerade-HOWTO-3.html
Being that your VPN seems to use UDP port 500 indicates that it is probably
an IPSec VPN in which case your firewall also needs to handle IP protocol
50.
Hope this helps.
Thanks,
Preston
> -----Original Message-----
> From: Netfilter.UPU <netfilter@upu.int>@INTERNET@HHC
> Sent: Tuesday, September 24, 2002 7:37 AM
> To: 'netfilter@lists.netfilter.org'
> Subject: Checkpoint VPN through Iptables
>
> Hi all,
>
> I'm hanged with the following problem.
> I want to access our enterprise network behind a Nokia checkpoint FW-UPU
> @a.b.c.d
> from a Windows 2k Checkpoint NG client @192.168.0.2
> behind my Linux Redhat 7.2 iptables 1.2.6a FW-HOME with eth0 @DHCP and
> eth1
> @192.168.0.1
>
> I have the following script
>
> $IPTABLES -F
> $IPTABLES -t nat -F
> $IPTABLES -t mangle -F
> $IPTABLES -P INPUT ACCEPT
> $IPTABLES -P FORWARD ACCEPT
> $IPTABLES -t nat -A POSTROUTING -s 192.168.0/24 -o eth0 -j MASQUERADE
>
> My little understanding of firewall, linux and iptables, makes me believe
> that :
> a) I've a quite secureless FW-HOME and my internal LAN is nated
> b) no matter the protocol, the src/dst ports etc, everything should pass.
> c) The checkpoint client should be able to access my enterprise VPN
> Is that right?
>
> My problem is that the client cannot access my enterprise VPN.
> I added some loging rules and it seems that
> My client uses UDP, src port 500 dst port 500.
> The FW-HOME send that to FW-UPU (prot udp, src port 500 dst port 500)
> (masquerading the IP@)
> The FW-UPU replies to FW-UPU (prot udp, src port 500 dst port 500)
> The FW-HOME replies : icmp port udp 500 unreachable
>
> I made another test before incriminating the Client
> I plugged it directly to my CableModem and it worked immediately.
> I check that it was configured correctly (IKE + Force UDP encapsulation +
> IKE over TCP)
> according to PhoneBoy http://www.phoneboy.com/faq/0141.html
> and http://www.phoneboy.com/faq/0372.html
> After this test I concluded that the Client is operational.
>
> Another info:
> It worked with a Redhat 7.0 + ipchains
> It didn't worked with ISA
>
> So for me the problem is located somewhere on FW-HOME.
> Anybody can help, explain, advice!?!?
>
>
>
> _________________________________________________________
> Birahim FALL
> Project Manager (Postal Technologie Centre)
> Universal Postal Union, PO Box, CH-3000 Bern 15 (Switzerland)
> Phone +41 313.503.372
> Fax +41 313.503.110
> Email mailto:birahim.fall@upu.int
>
>
>
>
^ permalink raw reply
* RE: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38)
From: Sven Koch @ 2002-09-24 14:15 UTC (permalink / raw)
To: Randal, Phil; +Cc: Linux-Kernel (E-mail)
In-Reply-To: <0EBC45FCABFC95428EBFC3A51B368C9501AF48@jessica.herefordshire.gov.uk>
On Tue, 24 Sep 2002, Randal, Phil wrote:
> You'll have to ask RedHat et al why they persist in backporting
> security patches to "old" releases of Apache (etc) instead of
> releasing the new versions. The effect is the same, with
> vulnerabilities being squashed, but the version numbers reported
> suggesting otherwise.
Because every new version gives you some new problems/incompatibilities,
which must not happen in a running production-environment.
And testing every security-update 4 weeks in the lab before putting
it into production would be worse.
c'ya
sven
--
The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)
^ permalink raw reply
* Re: SE-Linux packages
From: Russell Coker @ 2002-09-24 11:54 UTC (permalink / raw)
To: Brian May; +Cc: selinux
In-Reply-To: <200209201747.53722.russell@coker.com.au>
+<20020924030750.GA28681@snoopy.apana.org.au>
In-Reply-To: <20020924030750.GA28681@snoopy.apana.org.au>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200209241354.35906.russell@coker.com.au>
On Tue, 24 Sep 2002 05:07, Brian May wrote:
> On Fri, Sep 20, 2002 at 05:47:53PM +0200, Russell Coker wrote:
> > I have just updated my patch for unstable to the latest "coreutils" based
> > replacement for fileutils and shellutils. You may want to base your work
> > on that and maintain one package instead of two.
> >
> > My coreutils stuff is in http://www.coker.com.au/selinux/coreutils/
>
> Ok, I have compiled that for woody.
>
> I have also compiled your latest selinux package for woody.
>
> I have put both of these in my repository at the address previously
> given.
>
> However, there seem to be two policy errors, and I cannot see how to fix
> them:
>
> 1. run_deb_t is defined twice; once in run_deb.te, and once in
> dpkg.te (run_program macro).
run_deb.te should not exist any more. The diff created by dpkg-buildpackage
seems to have problems with deleted files.
> 2. mailman_queue_gph_t is not defined but required by the su_mini_domain
> macro.
I don't know the best way to solve this. It would probably be best for you to
devise a solution as you use gnome-pty-helper, it's difficult for me to solve
problems that don't occur for me...
> I have hacked solutions to these problems, but think a better solution
> is required.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [PATCH] per-interrupt stacks - try 2
From: David Howells @ 2002-09-16 14:09 UTC (permalink / raw)
To: Ingo Molnar; +Cc: David Howells, arjanv, dwmw2, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0209150747510.19045-100000@devserv.devel.redhat.com>
> > Do you have benchmarks or something to show that is this actually a
> > _significant_ problem?
>
> you need benchmarks to tell that pure per-IRQ stacks are bad for SMP
> performance?
No. I asked how _significant_ the difference is, as compared to the rest of
the accesses it makes.
> per-IRQ+per-CPU and pure per-CPU IRQ stacks should perform rougly equally
> well on SMP - with per-CPU IRQ stacks having lower runtime setup cost.
There are problems with purely per-CPU stacks if you run with interrupts
enabled. You theoretically ought to have a stack big enough to allow all
possible interrupts to be nested on one CPU.
And having non-uniform stack sizes of course introduces other
problems... notably the fact that you can no longer locate the thread_info
struct by means of AND-ing the stack pointer.
> there's a difference between bouncing 1-2 cachelines and bouncing a *full,
> dirtied stack*. The irq_desc[] bouncing is pretty much unavoidable (IRQs do
> need some global state) - the stack bouncing is just plain stupid and
> perfectly avoidable.
I wonder if it might be possible to invalidate just that bit of the
cache... though I suspect that's not worth it, even if it is.
David
^ permalink raw reply
* Re: [RFC] adding aio_readv/writev
From: John Gardiner Myers @ 2002-09-24 14:13 UTC (permalink / raw)
To: linux-aio; +Cc: linux-kernel
In-Reply-To: <20020924145225.J3160@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
Stephen C. Tweedie wrote:
>No, all you can infer from that is that "some method for avoiding
>small packets is important for networking." TCP_CORK already does
>that in Linux, for tcp at least, without requiring writev. (Of
>course, normal nonblocking writev is still there if you want it.)
>
TCP_CORK is indeed effective for avoiding small packets. Be that as it
may, the source data for network writes are frequently in discontiguous
buffers and writev is nonetheless still important for networking. The
alternative in the aio model is to waste a lot of resources delivering
io completions the application doesn't care about.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3537 bytes --]
^ permalink raw reply
* Re: 2.5.38: modular IDE broken
From: Bob_Tracy @ 2002-09-24 14:13 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0209231749050.13892-100000@chaos.physics.uiowa.edu>
Kai Germaschewski wrote:
> ===== Makefile 1.5 vs edited =====
> --- 1.5/drivers/ide/Makefile Wed Sep 18 20:11:21 2002
> +++ edited/Makefile Mon Sep 23 17:50:05 2002
> @@ -24,7 +24,7 @@
> obj-$(CONFIG_BLK_DEV_IDEDMA_PCI) += ide-dma.o
> obj-$(CONFIG_BLK_DEV_ISAPNP) += ide-pnp.o
>
> -ifeq ($(CONFIG_BLK_DEV_IDE),y)
> +ifdef CONFIG_BLK_DEV_IDE
> obj-$(CONFIG_PROC_FS) += ide-proc.o
> endif
I neglected to mention that the above patch (exactly the same, as it
turns out :-)) is how I forced the ide-proc.o build. The brokenness
extends deeper.
Specific example: proc_ide_read_geometry has the requisite EXPORT_SYMBOL()
wrapper in ide-proc.c, yet, I still end up with proc_ide_read_geometry_R*
unresolved at depmod time. In case anyone is wondering, I *did* do a
"make clean", manually cleaned out linux/include/modules to make *sure*
there wasn't any old cruft lying about, then ran "make dep && make bzImage &&
make modules && make modules_install". The depmod output quoted below is
the result of all that.
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.5.38; fi
> depmod: *** Unresolved symbols in /lib/modules/2.5.38/kernel/drivers/ide/ide-disk.o
> depmod: proc_ide_read_geometry_R50fed6f7
> depmod: *** Unresolved symbols in /lib/modules/2.5.38/kernel/drivers/ide/ide-floppy.o
> depmod: proc_ide_read_geometry_R50fed6f7
> depmod: *** Unresolved symbols in /lib/modules/2.5.38/kernel/drivers/ide/ide-probe.o
> depmod: do_ide_request
> depmod: ide_add_generic_settings
> depmod: create_proc_ide_interfaces_Rab2c600e
> depmod: ide_bus_type
> depmod: *** Unresolved symbols in /lib/modules/2.5.38/kernel/drivers/ide/ide.o
> depmod: proc_ide_create_Ra8e0f104
> depmod: ide_remove_proc_entries_R5a5a621b
> depmod: ide_add_proc_entries_Rce569c25
> depmod: destroy_proc_ide_drives_Ra54f63e5
> depmod: proc_ide_destroy_R35e1351c
> depmod: bus_unregister
> depmod: proc_ide_read_capacity_R46b2a30d
> depmod: create_proc_ide_interfaces_Rab2c600e
> depmod: ide_scan_pcibus
> make: *** [_modinst_post] Error 1
--
-----------------------------------------------------------------------
Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------
^ permalink raw reply
* Re: hpt370 raid driver
From: Wilfried Weissmann @ 2002-09-24 14:12 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Petr Slansky, alan, linux-kernel
In-Reply-To: <1032875703.2607.0.camel@localhost.localdomain>
Arjan van de Ven wrote:
> On Tue, 2002-09-24 at 15:29, Petr Slansky wrote:
>
>>Hi Alan!
>>do you know that there is a source code of driver for HPT370 raid at the
>>manufacturer web?
>>
>>http://www.highpoint-tech.com/370drivers_down.htm
>>http://www.highpoint-tech.com/hpt3xx-opensource-v13.tgz
>>
>>Maybe that this can be added to the kernel, there are many motherboards on the
>>market with such controller onboard. Is there any poblem with this driver?
>
>
> It's a binary only driver with some glue code.... not open source.
The header files are good. They show the structure of the raid signature
and some info about the event logs. They could be reused by the linux
module, however I do not know if the copyright is a problem there. Does
anyone know...?
Bye,
Wilfried
--
Ing. Wilfried Weissmann mailto: Wilfried.Weissmann@gmx.at
Benedikt-Schellingergasse 18/19a Tel.: +43 1 78 64 739
1150 Wien Mobil: +43 676 944 44 65
^ permalink raw reply
* RE: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38)
From: Randal, Phil @ 2002-09-24 14:04 UTC (permalink / raw)
To: Linux-Kernel (E-mail)
That's a moot point.
You'll have to ask RedHat et al why they persist in backporting
security patches to "old" releases of Apache (etc) instead of
releasing the new versions. The effect is the same, with
vulnerabilities being squashed, but the version numbers reported
suggesting otherwise.
Phil
---------------------------------------------
Phil Randal
Network Engineer
Herefordshire Council
Hereford, UK
> -----Original Message-----
> From: Gerhard Mack [mailto:gmack@innerfire.net]
> Sent: 24 September 2002 14:59
> To: Denis Vlasenko
> Cc: Larry Kessler; linux-kernel mailing list
> Subject: Re: [PATCH-RFC] README 1ST - New problem logging macros
> (2.5.38)
>
>
> On Tue, 24 Sep 2002, Denis Vlasenko wrote:
>
> > Regarding translation problem: it makes life easier to
> admins, i.e. you
> > enable Linux to be used by more stupid admins :-).
>
> Judging by the fact that most linux webservers were still running
> vunlerable versions of apache as of the last netcraft survey
> I'd say that
> goal has been already been hit. ;)
>
> Gerhard
>
>
> --
> Gerhard Mack
>
> gmack@innerfire.net
>
> <>< As a computer I find your faith in technology amusing.
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* How to set speed_limit_max for mdrecoveryd?
From: Cress, Andrew R @ 2002-09-24 14:01 UTC (permalink / raw)
To: 'Neil Brown'; +Cc: linux-raid
I couldn't find this is a quick scan of the code, and thought it should be
documented somewhere. Maybe I just have a blind spot. Can someone tell me
how to set the speed_limit_max variable for mdrecoveryd?
Andy Cress
^ permalink raw reply
* Re: SCSI woes (followup)
From: Russell King @ 2002-09-24 13:58 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi
In-Reply-To: <200209241346.g8ODkER09516@localhost.localdomain>
On Tue, Sep 24, 2002 at 09:46:14AM -0400, James Bottomley wrote:
> I think it's method of operation is misplaced.
I think it is misplaced. It locks the doors of devices that aren't even
in use, which is just plain stupid.
> However, for your case does simply moving the queue empty check to the top
> cause the problems to go away? (That would be hiding the problem not fixing
> it, but still...)
I #if 0'd it out, and it makes the problem go away.
One thing to note is the comment that Eric left in the code about it -
it seems to indicate that he believes it to be misplaced, but its there
because we have host drivers using the old error handling code.
I'm wondering if this behaviour only happens with host drivers that use
the new error handling. If so, one possibility would be to follow Eric's
suggestion there, and lock the door in the error handler "as Eric intended"
and leave that door locking behind for the old error handling.
Incidentally, I've found another weirdness in the code. We decide that
we need to lock the door based on the "was_reset" flag, which we clear.
However, st.c uses "was_reset" to decide whether to suspend operations
(due to a bus reset). The two uses of this flag seem to conflict each
other. How can we guarantee that st.c will see was_reset set if the
request function clears it? st.c appears to use scsi_request_fn, so
I guess there's a conflict of use there.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply
* Re: SE-Linux packages
From: Brian May @ 2002-09-24 3:07 UTC (permalink / raw)
To: Russell Coker; +Cc: selinux
In-Reply-To: <200209201747.53722.russell@coker.com.au>
On Fri, Sep 20, 2002 at 05:47:53PM +0200, Russell Coker wrote:
> I have just updated my patch for unstable to the latest "coreutils" based
> replacement for fileutils and shellutils. You may want to base your work on
> that and maintain one package instead of two.
>
> My coreutils stuff is in http://www.coker.com.au/selinux/coreutils/
Ok, I have compiled that for woody.
I have also compiled your latest selinux package for woody.
I have put both of these in my repository at the address previously
given.
However, there seem to be two policy errors, and I cannot see how to fix
them:
1. run_deb_t is defined twice; once in run_deb.te, and once in
dpkg.te (run_program macro).
2. mailman_queue_gph_t is not defined but required by the su_mini_domain
macro.
I have hacked solutions to these problems, but think a better solution
is required.
--
Brian May <bam@snoopy.apana.org.au>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: SE-Linux packages
From: Russell Coker @ 2002-09-24 11:54 UTC (permalink / raw)
To: Brian May; +Cc: selinux
In-Reply-To: <20020924030750.GA28681@snoopy.apana.org.au>
On Tue, 24 Sep 2002 05:07, Brian May wrote:
> On Fri, Sep 20, 2002 at 05:47:53PM +0200, Russell Coker wrote:
> > I have just updated my patch for unstable to the latest "coreutils" based
> > replacement for fileutils and shellutils. You may want to base your work
> > on that and maintain one package instead of two.
> >
> > My coreutils stuff is in http://www.coker.com.au/selinux/coreutils/
>
> Ok, I have compiled that for woody.
>
> I have also compiled your latest selinux package for woody.
>
> I have put both of these in my repository at the address previously
> given.
>
> However, there seem to be two policy errors, and I cannot see how to fix
> them:
>
> 1. run_deb_t is defined twice; once in run_deb.te, and once in
> dpkg.te (run_program macro).
run_deb.te should not exist any more. The diff created by dpkg-buildpackage
seems to have problems with deleted files.
> 2. mailman_queue_gph_t is not defined but required by the su_mini_domain
> macro.
I don't know the best way to solve this. It would probably be best for you to
devise a solution as you use gnome-pty-helper, it's difficult for me to solve
problems that don't occur for me...
> I have hacked solutions to these problems, but think a better solution
> is required.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: Checkpoint VPN through Iptables
From: Antony Stone @ 2002-09-24 13:57 UTC (permalink / raw)
To: 'netfilter@lists.netfilter.org'
In-Reply-To: <8F31D8DF00BBD411975C00508B6D6E65F89096@hermes.upu.int>
On Tuesday 24 September 2002 1:37 pm, Netfilter.UPU wrote:
> Hi all,
>
> I have the following script
>
> $IPTABLES -F
> $IPTABLES -t nat -F
> $IPTABLES -t mangle -F
> $IPTABLES -P INPUT ACCEPT
> $IPTABLES -P FORWARD ACCEPT
> $IPTABLES -t nat -A POSTROUTING -s 192.168.0/24 -o eth0 -j MASQUERADE
Simple enough.....
> My little understanding of firewall, linux and iptables, makes me believe
> that :
> a) I've a quite secureless FW-HOME and my internal LAN is nated
i agree.
> b) no matter the protocol, the src/dst ports etc, everything should pass.
From inside to outside, yes. Also reply packets provided you have
connection tracking support.
> c) The checkpoint client should be able to access my enterprise VPN
Maybe :-)
> My problem is that the client cannot access my enterprise VPN.
> I added some loging rules and it seems that
> My client uses UDP, src port 500 dst port 500.
Okay - that is the IKE protocol as used with IPsec.
> The FW-HOME send that to FW-UPU (prot udp, src port 500 dst port 500)
> (masquerading the IP@)
> The FW-UPU replies to FW-UPU (prot udp, src port 500 dst port 500)
> The FW-HOME replies : icmp port udp 500 unreachable
The reason is because you are performing NAT on outgoing packets, but here
you are getting a (completely separate) connection from the outside to the
inside, for which you do not have a NAT rule.
Here is what you should add:
iptables -A PREROUTING -t nat -i eth0 -p udp --sport 500 --dport 500 -j DNAT
--to a.b.c.d
where a.b.c.d is the internal IP address of your VPN client.
You will also need to set up the same translation for protocol 50 (ESP) in
order to allow that connection to be made after IKE has established the
encryption keys.
There is one thing you said which makes me think this is likely to work at
all:
> Another info:
> It worked with a Redhat 7.0 + ipchains
I presume that was also with NAT (masquerading) in operation ?
The reason I say that is because there are twoways of using IPsec: transport
mode and tunnel mode.
Transport mode does not work through NAT.
Tunnel mode does work through NAT.
Hope this helps,
Antony.
--
G- GIT/E d- s+:--(-) a+ C++++$ UL++++$ P+(---)>++ L+++(++++)$ !E W(-) N(-) o?
w-- O !M V+++(--) !PS !PE Y+ PGP+> t- tv@ b+++ DI++ D--- e++>+++ h++ r@? 5?
!X- !R K--?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.