RE: S/Key Password?
Yes, man skey really helped me out. I now think I understand the possible usefulness of it. Do you happen to know if that thing is Kerberos related? Thanks, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Yann Ramin Sent: Monday, March 25, 2002 11:34 PM To: William Michael Grim Cc: [EMAIL PROTECTED] Subject: Re: S/Key Password? S/Key is a one-time password scheme. Do a 'man skey' for more info. I'm not sure why its been default enabled in pam.conf, but I'm the wrong person to talk to for that :) Yann William Michael Grim wrote: Hi, I just upgraded to FreeBSD 4.5 and figured out how to finally get rid of S/Key Passwd: when I try to login through ssh. But what the hell was that? I don't know that password or anything. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Logging in (fortune cookie)
I would like to give thanks to whoever decided to make fortune cookies default in FreeBSD 4.5. Those little tips are teaching me a few things I didnt know. Thanks, Mike
Re: ATA still crashes on resume from suspend
It seems Kevin Oberman wrote: I saw that new versions of several ATA programs including ata-all.c had been loaded into stable. I hoped that this would fix the trap 12 when resuming from a suspend. No luck. Ian Dowses patches worked fine, but the code in stable still crashes. The fixes that I committed yesterday was for the vmware problems, the resume problem i not resolved yet. The patch floating around with using ATA_IMMEDIATE insted of ATA_WAIT_INTR might be the right solution, but I've not gotten so far yet... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
UDP jail bug patch (was Re: (PATCH) Re: jail bug with ircd-hybridin_pcbconnect()?)
I previously posted a patch to fix this UDP-in-jail bug which I believe
may have compromised the security of the jail. This patch shouldn't do
that.
It:
1. preserves the jail check in in_pcbconnect()
2. preserves the laddr+lport check in the beginning of in_pcbbind()
3. modifies no code outside of the jail path
4. only diddles with the PCB laddr which shouldn't have any side effects
because that is exactly what udp_output() is doing to cause the
problem in the first place
Arguably the real fix should be to fix the hash table and the bogosity in
udp_output(), but I don't have the time to commit to that.
--- in_pcb.c.oldMon Mar 18 23:57:57 2002
+++ in_pcb.cTue Mar 19 09:52:45 2002
@@ -501,6 +501,8 @@
int error;
if (inp-inp_laddr.s_addr == INADDR_ANY p-p_prison != NULL) {
+ if (inp-inp_lport != 0)
+ inp-inp_laddr.s_addr = htonl(p-p_prison-pr_ip);
bzero(sa, sizeof (sa));
sa.sin_addr.s_addr = htonl(p-p_prison-pr_ip);
sa.sin_len=sizeof (sa);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
For review: Revised sendmail startup settings
An issue came up on freebsd-stable today regarding the boot-time startup of
sendmail for users who are using other MTAs. The end result was that users
needed a way to completely prevent sendmail from trying to start at boot
time.
The current order of operations at boot time is:
# MTA
if ${sendmail_enable} == YES
start sendmail with ${sendmail_flags}
else
if ${sendmail_outbound_enable} == YES
start sendmail with ${sendmail_outbound_flags}
if ${sendmail_submit_enable} == YES
start sendmail with ${sendmail_submit_flags}
endif
# MSP Queue Runner
if [ -r /etc/mail/submit.cf] ${sendmail_msp_queue_enable} == YES
start sendmail with ${sendmail_msp_queue_flags}
endif
A few solutions were discussed and the patch represents what I feel to be
the best solution. Instead of rc.conf's sendmail_enable only accepting YES
or NO, it can now also accept NONE. If set to NONE, none of the other
sendmail related startup items will be done. While creating the patch, I
found an extra queue running daemon might be started that wasn't necessary
(it didn't hurt anything but it wasn't needed). That has been fixed in the
patch as well.
Therefore, the new order of operations (as shown in the rc.conf man page
and src/etc/defaults/rc.conf patches) is:
# MTA
if ${sendmail_enable} == NONE
# Do nothing
else if ${sendmail_enable} == YES
start sendmail with ${sendmail_flags}
else if ${sendmail_submit_enable} == YES
start sendmail with ${sendmail_submit_flags}
else if ${sendmail_outbound_enable} == YES
start sendmail with ${sendmail_outbound_flags}
endif
# MSP Queue Runner
if ${sendmail_enable} != NONE
[ -r /etc/mail/submit.cf] ${sendmail_msp_queue_enable} == YES
start sendmail with ${sendmail_msp_queue_flags}
endif
This will allow users to set sendmail_enable to NONE in /etc/rc.conf and
completely avoid any sendmail daemons.
I've also updated the /etc/mail/Makefile start target code to match the
new order of operations and added a new set of targets for the MSP queue
runner (start-mspq, stop-mspq, and restart-mspq).
Unless I hear any good arguments against this change, I'll commit it in the
next day or two (and MFC it a week later).
The patches for the two branches are available at:
FreeBSD 4.5-STABLE: http://people.freebsd.org/~gshapiro/smstart-STABLE
FreeBSD 5.0-CURRENT:http://people.freebsd.org/~gshapiro/smstart-CURRENT
Thanks go to Thomas Quinot [EMAIL PROTECTED] and
Christopher Schulte [EMAIL PROTECTED] for their
contributions to the idea and Mark Santcroos [EMAIL PROTECTED] for reminding
me to update /etc/mail/Makefile with the new startup routines.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
