Re: a small C program to test xdm's /dev/mem reading on your architecture
In article <[EMAIL PROTECTED]> Branden writes: >> I can't believe he actually intends to keep it like this.. >I'm going to #define DEV_RANDOM /dev/random for Linux systems. And Debian Hurd? Or does the Hurd not have /dev/random or /dev/urandom? I suspect that /dev/urandom may be the better choice, however. Jonathan.
Re: a small C program to test xdm's /dev/mem reading on your architecture
In article <[EMAIL PROTECTED]> Kusti writes: >I believe the /dev/mem gets read only in systems where no /dev/(u)random >exists. Actually, the standard configuration is that /dev/mem is read. The code to read from /dev/(u)random isn't activated in any situation in the standard upstream X distribution, and given that it contains an error that stops it from compiling[1] I suspect that it has only ever rarely been used. Obviously the correct thing to do is to shift to using /dev/(u)random by default. Jonathan.
Re: a small C program to test xdm's /dev/mem reading on your architecture
[Apologies to readers of debian-sparc, who have already received a copy of this] In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] write: [XDM randomness] >/dev/random? /dev/urandom? You are kidding. This randmomness is used >to create authorisation cookies for X which in my understanding provide >ZERO security. Use plain libc rand() and the security is exactly the same. In the situation where the X session is in practice running over unix sockets (or other configurations where all the data stays local to the machine without being vulnerable to network (or other) sniffing attacks)[1], the cookies in question provide the security that they were designed for - namely requiring a significant proportion of the space available to said cookies to be trawled to be able to send authenticated requests to the X server.[2] Jonathan. [1] Although, said server may be listening for tcpip connections, or those of other protocols to which the attacker can send their requests. [2] Having looked at the code, it is not obvious to me that the entropy produced in said cookies doesn't have a maximum of 32 bits, even if the cookie is longer than that.
Re: a small C program to test xdm's /dev/mem reading on your architecture
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] write: [XDM randomness] >/dev/random? /dev/urandom? You are kidding. This randmomness is used >to create authorisation cookies for X which in my understanding provide >ZERO security. Use plain libc rand() and the security is exactly the same. In the situation where the X session is in practice running over unix sockets (or other configurations where all the data stays local to the machine without being vulnerable to network (or other) sniffing attacks)[1], the cookies in question provide the security that they were designed for - namely requiring a significant proportion of the space available to said cookies to be trawled to be able to send authenticated requests to the X server.[2] Jonathan. [1] Although, said server may be listening for tcpip connections, or those of other protocols to which the attacker can send their requests. [2] Having looked at the code, it is not obvious to me that the entropy produced in said cookies doesn't have a maximum of 32 bits, even if the cookie is longer than that.
Re: 2.4.19-ac1 kernel compilation
> On Mon, Aug 05, 2002 at 04:52:39PM +0100, Jonathan Amery wrote: > > > > So long as you don't want RAID. Any ETA on sparc32 running well with > > 2.4.x? > > There is no ETA, because there is no one really maintaining sparc32 > anymore. Feel free to pitch in, but we have plenty of testers and not > many people with enough time to devote to actually fixing things. > Ahh... Is there a list of things that are known not towork anywhere? (other than the archives of various mailing lists?) J.
Re: 2.4.19-ac1 kernel compilation
In article <[EMAIL PROTECTED]> you write: >On Sun, Aug 04, 2002 at 12:14:35PM +0200, Wilmer van der Gaast wrote: >> What's the best kernel for sun4m/sparc5 machines exactly? I'm told I >> should be running 2.4, but I'm not quite sure about that anymore... >Heh, someone told you wrong. For sparc32, the most stable kernel is >2.2.20. So long as you don't want RAID. Any ETA on sparc32 running well with 2.4.x?
Re: RAID1 on sparc64
In article <[EMAIL PROTECTED]> you write: >Hello, > >I have installed Debian 2.2 on a Sun Enterprise 420R. Everything seems to = >be working alright except software RAID, which is working fine on our x86 = >machines. The patch itself installs cleanly as does the kernel build, it = >is just the 'fdisk' and 'mkraid' tools that give me issues: > A couple of known problems with RAID on sparc on 2.2 are: - The superblock contains a 64bit value (event counter) on a 32 bit boundary, and so ends up the wrong size - only MS-DOS partitions support auto-detect, and you really need autodetect for reliable RAID operation. There is a patch for the former at http://www.cse.unsw.edu.au/~neilb/patches/raid-2.2.20/raid-2.2.20.patch It is Ingo Molnar's patch applied to 2.2.20, and with the superblock event counter tidied up as is done in 2.4. However I believe that raid-sets made like this will not be forwards compatible with 2.4 kernels - I suggest you ask the linux-raid list for further information. Jonathan.
Re: HELP 2.4 booting on a serial console (resend)
In article <[EMAIL PROTECTED]> you write: >Jonathan Amery wrote: >> Right - I've just been talking to the linux-raid people about raid on >> sparc (if you search for my name on their archive then it'll come up), >> the conclusion being that: >> >> a) raid in the stock 2.2.X kernels won't work on sparc >> b) there are patches to make it (probably) work, but they haven't >> been heavily tested. >> c) patched 2.2.X raid systems won't be forwards compatible with 2.4.X >> d) 2.4.X raid stuff should work. > >That's of no or little use if you're on a sparc32 system. > Well, yes :(. (I also have a sparc32 system). If you really need 2.2 with raid on sparc then the patches are available. Jonathan.
Re: HELP 2.4 booting on a serial console (resend)
In article <[EMAIL PROTECTED]> you write: >Ok, > >I go for 2.2.20, but still can't > >2) - get raid stuff work, at least with 2.2.20 kernel shipped with potato >Debian distrib (when I'll come to have stock 2.2.20 run , I may try :) > Right - I've just been talking to the linux-raid people about raid on sparc (if you search for my name on their archive then it'll come up), the conclusion being that: a) raid in the stock 2.2.X kernels won't work on sparc b) there are patches to make it (probably) work, but they haven't been heavily tested. c) patched 2.2.X raid systems won't be forwards compatible with 2.4.X d) 2.4.X raid stuff should work. Jonathan.
Re: strange ssh problem with dns...
In article <[EMAIL PROTECTED]>, Pierfrancesco Caci <[EMAIL PROTECTED]> wrote: > >Hello, I receive these messages whenever someone connects to an >ultra10 running linux 2.4.10-pre2 > >Nov 9 12:06:36 etabeta sshd[766]: Could not reverse map address 172.16.1.9. >Nov 9 12:06:41 etabeta sshd[766]: packet_set_maxsize: setting to 4096 > what is the output of `host 172.16.1.9` and `host ` where is the fqdn that the first host command gave you as the output. (The output of host should the first time be something like: 13.100.168.192.IN-ADDR.ARPA domain name pointer vermont.petrologic.co.uk in which case is vermont.petrologic.co.uk) -- Jonathan Amery. #The world is collapsing around our ears ###__oI turned up the radio, but I can't hear it. ###'/ - REM, Radio Song
Re: Sun Box will not auto boot
In article <[EMAIL PROTECTED]> you write: >I have my Sparc 5 up and running now. I have a Debian distro of Linux >running on it. I want to make it a firewall but I have one problem. When I >boot it up there is a message about a bad argument from the boot prom. If I >boot it from the boot floppy I made it boots. This means that I must type >the command "boot floppy" every time I boot up. If I do not type the command >it can not boot. What to I have to do to boot from the hard drive >automatically at boot up time? > Could you please report the messages the machine gives on boot up? Jonathan.
