Re: how to write custom init

[diman]

On Fri, 12 Jan 2001, Soumen Biswas wrote:

> Hi , 
> 
> What are the points to be observed while writing custom init 
>  
> I am currently doing something like :  
> /* 
>   1.  never exit 
>2. open fd 0,1 & 2 
>3. link statically  */
> 
> int main( int argc, char **argv )
> {
> int fd ;
> char cmd[128] = {0};
> 
> fd = open( "/dev/console", O_RDWR );
> dup(fd);
> dup(fd);
> 
>  while( 1 ) {
>  printf( "comm>" ); fflush( stdout );
>  fgets( cmd, sizeof(cmd ), stdin );
> 
>  if( memcmp( "init", cmd , 4 ) == 0 ) 
>{ close(0); close(1);close(2); execv("/init/sbin", argv ); }

Why /init/sbin ??

> 
>  if( memcmp( "quit", cmd, 4) == 0 ) reboot( RB_AUTOBOOT );
>  } /* while */
> 
> /* should not reach here */
> return 0 ;
> }
> 
> 
> Am I missing something ?
> 
> Thanx & Regards 
> soumen
> 
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Need help for kernel crash dump analysis

[diman]

On Fri, 12 Jan 2001, Xavier Galleri wrote:

> OK, let's make it a bit clearer !
...
[skiped]
> 
> Now, if you've read my first mail, I was actually asking for help onhow 
> to dump the stack of an interrupted process with GDB when the 
> kernelcrash occurs in the context of an isr. Actually, I would like to 
> know how I could dump the stack of *any* process at the time of the 
> crash. This way, I would be able to see where my user-land daemon was 
> lying in the kernel when the interrupt occurs.


To dump stack of *any* (all) process you may write a little kld 
wich will:

1) go through a process list,
2) get tf_eip, tf_esp, tf_ebp of a process
3) get p->p_vmspace 
4) read process stack frames and all you need by manually
   written routine based on procfs_rwmem and old good 'pread'
   (which dosn't work now)

Another way is to go through proc list and coredump all the
processes for future manual analisys.

I like such way. 

Can anybody point me to some difficults wich can appear while
implementing this?

> 
[skiped]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: huh

[diman]

gdb(1) does this definitely. truss(1) gdb for the first and start
thinking.


On Tue, 13 Feb 2001, milunovic wrote:

> -BEGIN PGP SIGNED MESSAGE-
> 
> Huh thanks those who helped me with some ptrace() examples for Linux.
> But I cann't still figure how to trace programm execution under FreeBSD...
> please can anybody help me or give me some source example to see:o)
> Thank you
> - --
> Vojislav Milunovic
> [EMAIL PROTECTED]
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
> 
> iQEVAwUBOomhKC3gPLld8IkLAQF40gf/WFbgRs2B3uXVQMtegz9JVfRd19VOboxB
> /ER3e0usC9tsoBiQ/t+qSoVcZgTT+ARSEqAkmb1vo+dzaACu676G+mrdDo64eDcI
> TBWtimmAPUjhjc3kWasBaSi5RITm/E5Sw0dRt0ToAN7YcXoZxvQ5bxQuaMr6/ZMX
> LRdHdNbK2K3H4BQoknuCu/f7br/TcwXct+vF8Cn6iwXoUhpzOmU5Bkec4O1lBqTN
> TVmDQLRP6dRE0t/NX1TGSwoz6o2dCO/OtSnM9HCZ8eknOkl/nhKd2KxT8X8h7t6T
> V4tKi5syqrPZBBkP0v9P3AWcLaFDbSO6s9plJXbaYrijT0N/gqnFmQ==
> =KdCL
> -END PGP SIGNATURE-
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: warning in free():

[diman]

On Thu, 22 Feb 2001, mouss wrote:

> Now having free() write to stdout/stderr isn't necessarily a good thing
> for daemons. If the message goes through a socket, it'll be hard to
> debug, which was the original intent.
> 
> I suggest having some way so that when a program becomes a daemon,
> it can set some "silent-libc" or "libc messages go to logs" instead of
> using stdout/stderr.
> 
> Wouldn't it not be cool if err() and warn() had the capability of using syslog
> instead of a file or std* when needed. err_set_file allows one to use a file
> instead. How about allowing the use of syslog?

Open AF_UNIX socket to syslogd and then use err_set_file()
to redirect all err/warn messages to syslogd instead of
stdin/stdout. That should help you debug daemons.

Best Regards




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: warning in free():

[diman]

On Thu, 22 Feb 2001, mouss wrote:

> At 18:37 22/02/01 +0200, diman wrote:
> 
> >Open AF_UNIX socket to syslogd and then use err_set_file()
> >to redirect all err/warn messages to syslogd instead of
> >stdin/stdout. That should help you debug daemons.
> 
> I agree, but one of the nice things about syslog interface is that it hides
> all the socket/device stuff. so getting back to the socket api is
> somewhat unsatisfactory.

Yes, it's a bit dirty workaround. But openlog() returns void.
Returning pointer to a structure from wich I can obtain file 
descriptor has more sense for several reasons. It would be nice
to be able get current LogFile, LogTag, LogStat and LogFacility
from openlog().

> 
> Also, I think having this directly in err() and warn() and friends would be
> more elegant. and this doesn't seem hard to do. something like using
> a function pointer to use fprintf or syslog, and an additionnal void* to use
> either err_file or syslog priority.
> 
> Does this sound ok or is it an unuseful complication of code?

I see a sense in your words. Linking a daemon with a libs wich will
break control connection by diagnostic messages is not a dream.
Having that messages on the console and in the log file is
helpful under debug time. There are some points:

 1. If daemon want syslog, it should use syslog().
 2. If daemon want warn and exit, it should use warnx.
 3. If it doesn't want stderr, it should use err_set_file.

*4. If daemon doesn't want libc talking to remote end and
breaking a control connection or daemon doesn't want 
remote end to know about internal fault, it should
be able to redirect libc output.
*5. Daemon feels good to syslog above libc messages
*6. To do 5 it would be nice to have ERR_TO_SYSLOG reserved
integer for the err_set_file(void* vfp). So,

err_set_file ( ERR_TO_SYSLOG ) ;

will say libc to use LogFile and current syslog context
to write all err/warn messages instead of stderr.

*7. Approach described above doesn't break any current
app/daemons and nothing have to be rewritten because
ERR_TO_SYSLOG is 0xfffa (for example). Approach
is trivial to implement.

 8. Not linked well to the speach but openlog() should
not return void but pointer to the struct with
LogFile, LogTag, LogStat and LogFacility fields.


That is my view of the subject.
Best Regards, diman.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: easy way to crash freebsd

[diman]

Hello, I found a bit more ecsotic way to do this:
- put your fdd to a piece of paper
  to make it roll a bit slower
- mount floppy and initiate some
  write operation
- regulating the preassure to the device
  you can achive the effect
  (I/O err., autom. reboot in progress :P)



On Fri, 2 Mar 2001, Dan Phoenix wrote:

> 
> 
> symbolic link /etc/resolv.conf
> to a non-existant filethrow a bunch of connections at it
> and watch it reboot.
> 
> 
> --
> Dan
> 
> +--+ 
> |   BRAVENET WEB SERVICES  |
> |  [EMAIL PROTECTED]|
> | make installworld|
> | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail |
> | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases |
> +__+
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: FreeBSD asm problem

[diman]

ex.S
#include 
.globl  main
main:   popl%eax/* cick ret */
popl%eax/* cick argc */
movl(%esp),%eax /* eax=av */
movl$fname, %ebx/* ebx=fname */
movl%ebx,(%eax) /* av[0]=fname */
pushl   %ebx/* needs to be on the stack too */
movl$SYS_execve,%eax/* execve */
callsyscall
movl$SYS_exit,%eax  /* exit */
callsyscall
syscall:
int $0x80
ret
fname:  .asciz  "/bin/sh"


On Tue, 13 Mar 2001, Nickolay A. Kritsky wrote:

> Hi all!
> It seems to me that you guys are my last hope, but if  i am asking in the
> wrong place - sorry.
> 
> I wrote my first asm program for FreeBSD:
> 
> section.code
> global _start
> _start:
> push dword envp
> push dword argvp
> push dword fname
> mov eax,59  ; execve
> int 80h
> hlt   ; i should never get here
> 
> section .data
> fname db '/bin/sh',0
> envp dd 0
> argvp dd 0
> ;End of program
> 
> after compiling and linking i run it and got SIGBUS error
> when run under gdb i can see that int 80h returns with eax=2 (ENOENT? does
> it mean file not found?)
> 
> I have a feeling that i have missed something very important.
> 
> Thank you.
> NKritsky - SysAdmin InternetHelp.Ru
> http://www.internethelp.ru
> e-mail: [EMAIL PROTECTED]
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

ptrace(PTRACE_SYSCALL,...

[diman]

Hello, guys

I'm porting ltrace to FreeBSD and have one little question.
ltrace uses non-standard PTRACE_SYSCALL request, which tells
the kernel to stop traced process on every syscall entry
and notify the parent.

It makes us possible to trace child's syscalls and *catch
execve/xfork events* and many more. BTW, that request 
is non-standard and FreeBSD doesn't support it. 

So, guys, what is a right way for a parent to catch 
child making syscall under FreeBSD? I have dosen
k-mode solutions but how to do that from user-space?

Thanks you very much!



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ptrace(PTRACE_SYSCALL,...

[diman]

Thank you much, procfs events really helps !

To make truss work without procfs mounted, it's easy
to cut 1 line of PIOCBIS procfs_ioctl() code and
put it to a new PTRACE_SYSCALL ptrace() request - 
really it is a same things with different names.

Then replace all open/read/write/close with respective
ptrace() calls and umount /proc =)

I want port to work on older FreeBSD systems too, so now 
I'll use fcntl.h.


On Mon, 23 Apr 2001, Robert Watson wrote:

> 
> Sounds like this might also be useful to make a procfs-free truss
> 
> Robert N M Watson FreeBSD Core Team, TrustedBSD Project
> [EMAIL PROTECTED]  NAI Labs, Safeport Network Services
> 
> On Mon, 23 Apr 2001, diman wrote:
> 
> > 
> > Hello, guys
> > 
> > I'm porting ltrace to FreeBSD and have one little question.
> > ltrace uses non-standard PTRACE_SYSCALL request, which tells
> > the kernel to stop traced process on every syscall entry
> > and notify the parent.
> > 
> > It makes us possible to trace child's syscalls and *catch
> > execve/xfork events* and many more. BTW, that request 
> > is non-standard and FreeBSD doesn't support it. 
> > 
> > So, guys, what is a right way for a parent to catch 
> > child making syscall under FreeBSD? I have dosen
> > k-mode solutions but how to do that from user-space?
> > 
> > Thanks you very much!
> > 

Thanks & Peace


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Weird PT_DETACH

[diman]

To attach debugger to a process please use PT_ATTACH
request instead of PT_DETACH. Use PT_DETACH to stop
debugging a process and leave it alone.


On 30 May 2001, Jiangyi Liu wrote:

> Hi all,
> 
> The ptrace(2) man page is probably outdated. I used PT_DETACH in the
> following code, but it didn't run ./test. I also tried to use
> ptrace(PT_DETACH, pid, (caddr_t)1, 0) to detach, but it failed too.
> 
> BTW, if I omit wait(0) and ptrace(PT_DETACH, ...) in the code, after
> it runs there is a process sticking to the system. Even kill -9 can't
> kill it.
> 
> $ ps aux | grep jyliu
> ...
> jyliu423  0.0  0.1   216  100  p2  TX7:41AM   0:00.00  (test)
> ...
> $ kill -9 423
> $ ps aux | grep jyliu
> ...
> jyliu423  0.0  0.1   216  100  p2  TX7:41AM   0:00.00  (test)
> ...
> 
> So it's still there. Quite funny. Any clue?
> 
> Jiangyi
> 
> ---code begins here
> #include 
> #include 
> #include 
> 
> int main()
> {
> pid_t pid;
> 
> if(!(pid=fork())) {
> /* child */
> ptrace(PT_TRACE_ME, 0, 0, 0);
> puts("child speaking");
> execve("./test", NULL, NULL);
> } else {
> wait(0);
> ptrace(PT_DETACH, pid, 0, 0);
> exit(0);
> }
> }
> ---code ends here
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Weird PT_DETACH

[diman]

If i understand ptrace(2) manual page correctly,
you should use 
ptrace(PT_DETACH,pid,(caddr_t)1,0)
instead of 
ptrace(PT_DETACH,pid,0,0) .

BTW you code is *very hard to debug* on my 4.1.1 :)
What your uname -a tells you?



On Wed, 30 May 2001, Jiangyi Liu wrote:

> Hi,
> 
> Sorry I didn't point out that my purpose is just to stop the debugging and leave the 
>subprocess alone. It's supposed after PT_DETACH, the subprocess should continue, but 
>it didn't. That's what I felt weird. Any clue?
> 
> ----- Original Message - 
> From: "diman" <[EMAIL PROTECTED]>
> To: "Jiangyi Liu" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 30, 2001 8:54 PM
> Subject: Re: Weird PT_DETACH
> 
> 
> > 
> > 
> > To attach debugger to a process please use PT_ATTACH
> > request instead of PT_DETACH. Use PT_DETACH to stop
> > debugging a process and leave it alone.
> > 
> 
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Weird PT_DETACH

[diman]

Hope your program not named "./test"  ??
I changed it to /bin/sh and it works just fine.
It was hard to debug due to my own proggie bug :)
bb.


#include 
#include 
#include 

int main()
{
 pid_t pid;
 
 if(!(pid=fork())) {
 /* child */
 ptrace(PT_TRACE_ME, 0, 0, 0);
 puts("child speaking");
 execve("./test", NULL, NULL);  <-- ??
 } else {
 wait(0);
 ptrace(PT_DETACH, pid, (caddr_t)1, 0); <-- also
 exit(0);
 }
}





On Wed, 30 May 2001, Jiangyi Liu wrote:

> 
> > 
> > If i understand ptrace(2) manual page correctly,
> > you should use 
> > ptrace(PT_DETACH,pid,(caddr_t)1,0)
> > instead of 
> > ptrace(PT_DETACH,pid,0,0) .
> > 
> 
> If you read my first post again, you will know that indeed I've tried to use 
>(caddr_t)1 but failed too.
> 
> > BTW you code is *very hard to debug* on my 4.1.1 :)
> > What your uname -a tells you?
> 
> Why? My box is 4.3-STABLE.
> 
> Jiangyi
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

FIX needed. Was: Weird PT_DETACH

[diman]

Hello, guys.
Jiangui Liu told right thing - next code fragment
creates a SIGKILL immune allproc entry:


--begin--
#include 
#include 
#include 
#include 

int main() {
ptrace(PT_TRACE_ME, 0, 0, 0);
puts("never kill me");
execve("/bin/sh", NULL, NULL);
}
--end---


Ok, lets see..

> ./im
[1]+ Stopped./im
> ps -O flags -p 473
  PID   F  TT  STAT  TIME COMMAND
  4735806  v1  TX 0:00.00  (sh)
>

We have:
flags = 0x05806 = P_CONTROLT | P_INMEM | P_TRACED | P_WAITED | P_EXEC
state = SSTOP  

In such state SIGKILL never will be delivered (+1000 kern_sig.c)
Attached is an *attempt* to fix the problem - please
expertise and correct me (patch made against 4.1.1R)


Another problem(?) Jiangui found considers PT_DETACH ptrace(2)
call.  While i'm attaching to a running process via PT_ATTACH,
PT_DETACH works well as expected.
If i instead use PT_TRACE_ME -> execve -> PT_DETACH,
child always got killed by SIGTRAP.
I'm not sure it's a bug - needs play a bit more with gdb... ..

Attached is a simple program i used for tests.
Note that Jiangyi Liu reported same effects on 4.3-S.

Sorry Jiangyi Liu, I wrong understood you yesterday -
needs more more more sleeping :~)

Best Regards.

> On 30 May 2001, Jiangyi Liu wrote:
> 
> > Hi all,
> > 
> > The ptrace(2) man page is probably outdated. I used PT_DETACH in the
> > following code, but it didn't run ./test. I also tried to use
> > ptrace(PT_DETACH, pid, (caddr_t)1, 0) to detach, but it failed too.
> > 
> > BTW, if I omit wait(0) and ptrace(PT_DETACH, ...) in the code, after
> > it runs there is a process sticking to the system. Even kill -9 can't
> > kill it.
> > 
> > $ ps aux | grep jyliu
> > ...
> > jyliu423  0.0  0.1   216  100  p2  TX7:41AM   0:00.00  (test)
> > ...
> > $ kill -9 423
> > $ ps aux | grep jyliu
> > ...
> > jyliu423  0.0  0.1   216  100  p2  TX7:41AM   0:00.00  (test)
> > ...
> > 
> > So it's still there. Quite funny. Any clue?
> > 
> > Jiangyi
> > 
> > ---code begins here
> > #include 
> > #include 
> > #include 
> > 
> > int main()
> > {
> > pid_t pid;
> > 
> > if(!(pid=fork())) {
> > /* child */
> > ptrace(PT_TRACE_ME, 0, 0, 0);
> > puts("child speaking");
> > execve("./test", NULL, NULL);
> > } else {
> > wait(0);
> > ptrace(PT_DETACH, pid, 0, 0);
> > exit(0);
> > }
> > }
> > ---code ends here


#include 
#include 
#include 
#include 
#include 

int main(int ac, char **av) {
pid_t pid=0;
int s,  i=0;
 
if ( ac > 1) {
pid = atoi( av[1] );

if ( 0 > ptrace(PT_ATTACH,pid,0,0) ) {
printf("can't attach to %d\n",pid);
exit(0);
}

} else
pid = fork();

if ( !pid ) { /* child - unreached if attaching mode */
 
/* sleep a bit to make parent able issue wait */
usleep(10);
ptrace(PT_TRACE_ME, 0, 0, 0);

puts("-- child speaking");
execve("/bin/df", NULL, NULL);

} else /*wait for child/inferior*/

  while ( 0 < waitpid(pid,&s,0) ) {

if ( WIFSIGNALED(s) ) {
printf("-- %d exited %s\n",
pid, WCOREDUMP(s) ? "core dumped": "" );
exit(0);
}


if ( WIFEXITED(s) ) {
printf("-- %d exited with status %d\n", \
pid, WEXITSTATUS(s) );
exit(0);
}

if ( WIFSTOPPED(s) ) {

printf("-- %d stopped on signal %d\n",  \
pid, WSTOPSIG(s) );

if( !i ) {
printf("-- PT_CONTINUE it..\n");
ptrace(PT_CONTINUE, pid, (caddr_t)1, 0);
} else {
printf("-- PT_DETACH it..\n");
ptrace(PT_DETACH, pid, (caddr_t)1, SIGCONT);
}
i ++;

} else
printf("/* not reached */\n");  

}
}





*** /usr/src/sys/kern/kern_sig.c.oldThu May 31 12:25:52 2001
--- /usr/src/sys/kern/kern_sig.cThu May 31 12:19:19 2001
***
*** 1120,1136 
  
case SSTOP:
/*
 * If traced process is already stopped,
 

Re: Query: How to tell if Microsoft is using BSD TCP/IP code?

[diman]

Hi,
I agree with Serger Babkin - strings(1) wouldn't help.
Main keywords are:  ndis.vxd ,  vip.386 ,  vtcp.386 .
Any DLL's has nothing common with TCP/IP stack  - at least on md 9x.


Sergey Babkin wrote:

> I know one way but it's a hard one: disassemble and manually decomiple
> the code and compare it with the BSD code. I've once done such
> a research on the HP-UX pty code (for other reasons) and it matched
> the BSD code practically exactly except for the added spin locks.
>
> -SB


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

DDB & mp3's

[diman]

Hi, folks.
When I switch to DDB to check something or debug something
usefull, mp3 player process (mpg123) hangs up and dissonate
me. So guys how do you do in such a case? I'm shure that
I'm not one having such a problem. ;-)

Maybe someone has allready ported mp3's player to kernel,
or even built it in DDB? 

What would be your suggestion?


Thanks & Peace.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Project idea: Put PVM in /usr/bin/make

[diman]

I found it interesting. I have 3 idle boxes out here and
friend of mine has ~20, and parallel make is a dream.
Don't know about someone else, I'm giving your proposal
a try.. :-)


On Mon, 21 Jan 2002, Poul-Henning Kamp wrote:

>
> /usr/bin/make already have hooks for remote execution of jobs when
> running parallel.  All that is missing before we can do distributed
> parallel make worlds is that somebody writes the necessary hooks
> based on PVM...
>
> This is a really simple task, and the best of it all is that one
> does not need a cluster of machines to test it:  Using jail(8) you
> can run a PVM cluster of any size on one machine.
>
> Any takers ?
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: MAC address

[diman]

On Sat, 9 Feb 2002 "."@babolo.ru wrote:

> Vladislav V. Anikiev writes:
> >   The MAC address - I meen The Media Access Control address (i.e., ethernet
> > hardware address, not IP address). I want to use the default hardware (not
> > current physical ) address in my license management software.
> MAC address is stored in flash.
> It is easy to reprogram any MAC in many NICs

I have once pressed reset while running vendor's  'test NIC EEPROM'
program and have found after reboot that my card has
A5:A5:A5:A5:A5:A5 MAC now :-)

But if you know an EEPROM layout and how to read/write it you can
use your network card as real electonic key like HASP :-)





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message