Re: faithd fcntl diff
On 11 February 2013 07:05, Todd T. Fries t...@fries.net wrote: In light of nat64 in pf(4), what purpose does faithd(8) serve anymore? I played with it a bit over a decade ago, but don't recall having any use for it in the last number of years. I vote it gets tedu'ed. I vote for it too, I remember suggesting it last year. Penned by David Hill on 20130209 12:53.51, we have: | Anyone want to OK and commit? | | On Sun, Jan 20, 2013 at 05:19:18PM -0500, David Hill wrote: | O_NONBLOCK is set with F_SETFL | | Index: usr.sbin/faithd/tcp.c | === | RCS file: /cvs/src/usr.sbin/faithd/tcp.c,v | retrieving revision 1.12 | diff -N -u -p usr.sbin/faithd/tcp.c | --- usr.sbin/faithd/tcp.c8 Sep 2002 01:20:15 - 1.12 | +++ usr.sbin/faithd/tcp.c20 Jan 2013 22:17:13 - | @@ -206,7 +206,7 @@ relay(int s_rcv, int s_snd, const char *service, int d | FD_ZERO(readfds); | FD_ZERO(writefds); | FD_ZERO(exceptfds); | -fcntl(s_snd, F_SETFD, O_NONBLOCK); | +fcntl(s_snd, F_SETFL, O_NONBLOCK); | oreadfds = readfds; owritefds = writefds; oexceptfds = exceptfds; | if (s_rcv = FD_SETSIZE) | exit_failure(descriptor too big); | -- Todd Fries .. t...@fries.net |\ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC\ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com\ 1.866.792.3418 (FAX) | PO Box 16169, Oklahoma City, OK 73113 \ sip:freedae...@ekiga.net | ..in support of free software solutions. \ sip:4052279...@ekiga.net \ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: faithd fcntl diff
On 2013/02/11 00:05, Todd T. Fries wrote: In light of nat64 in pf(4), what purpose does faithd(8) serve anymore? ftp translation; but I doubt anyone uses that. I played with it a bit over a decade ago, but don't recall having any use for it in the last number of years. I vote it gets tedu'ed. +1. don't forget the kernel parts!
Re: faithd fcntl diff
Date: Mon, 11 Feb 2013 00:05:29 -0600 From: Todd T. Fries t...@fries.net In light of nat64 in pf(4), what purpose does faithd(8) serve anymore? I played with it a bit over a decade ago, but don't recall having any use for it in the last number of years. I vote it gets tedu'ed. I fear it's too late in the game to do that now. Bring this up again after unlock. Meanwhile, perhaps that bug (if it really is a bug) should be fixed?
Re: faithd fcntl diff
Penned by Mark Kettenis on 20130211 10:00.08, we have: | Date: Mon, 11 Feb 2013 00:05:29 -0600 | From: Todd T. Fries t...@fries.net | | In light of nat64 in pf(4), what purpose does faithd(8) serve anymore? | | I played with it a bit over a decade ago, but don't recall having any use | for it in the last number of years. | | I vote it gets tedu'ed. | | I fear it's too late in the game to do that now. | | Bring this up again after unlock. Meanwhile, perhaps that bug (if it | really is a bug) should be fixed? I spoke with David Hill on irc and turns out it was found during a O_CLOEXEC cleanup. Since we strive for correct code everywhere, makes sense to me to commit the fix, so we put better 'last version before teduing' code in the attic after unlock. Thanks, -- Todd Fries .. t...@fries.net |\ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC\ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com\ 1.866.792.3418 (FAX) | PO Box 16169, Oklahoma City, OK 73113 \ sip:freedae...@ekiga.net | ..in support of free software solutions. \ sip:4052279...@ekiga.net \ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: add scan_ffs to fsck and fsck_ffs see also lists
On 02/10/13 21:42, Scott McEachern wrote: I think these might be helpful: Sorry, I didn't have a machine with the sources available when I sent that. Is this more helpful or is it too late? Index: fsck.8 === RCS file: /cvs/src/sbin/fsck/fsck.8,v retrieving revision 1.31 diff -u -p -r1.31 fsck.8 --- fsck.8 31 May 2007 19:19:44 - 1.31 +++ fsck.8 11 Feb 2013 16:39:49 - @@ -176,4 +176,5 @@ file system table .Xr growfs 8 , .Xr mount 8 , .Xr newfs 8 , +.Xr scan_ffs 8 , .Xr rc 8 Index: fsck_ffs.8 === RCS file: /cvs/src/sbin/fsck_ffs/fsck_ffs.8,v retrieving revision 1.22 diff -u -p -r1.22 fsck_ffs.8 --- fsck_ffs.8 3 Mar 2010 15:05:38 - 1.22 +++ fsck_ffs.8 11 Feb 2013 16:50:13 - @@ -304,4 +304,5 @@ are fully enumerated and explained in Ap .Xr growfs 8 , .Xr mount_ffs 8 , .Xr newfs 8 , +.Xr scan_ffs 8 , .Xr rc 8 -- Scott McEachern https://www.blackstaff.ca
Re: add scan_ffs to fsck and fsck_ffs see also lists
On Sun, Feb 10, 2013 at 09:42:58PM -0500, Scott McEachern wrote: I think these might be helpful: i've just committed this. note (for future diffs ;) scan_ffs should be listed after rc. jmc --- fsck.8.orig Sun Feb 10 21:34:32 2013 +++ fsck.8 Sun Feb 10 21:37:48 2013 @@ -176,4 +176,5 @@ file system table .Xr growfs 8 , .Xr mount 8 , .Xr newfs 8 , +.Xr scan_ffs 8 , .Xr rc 8 --- fsck_ffs.8.orig Sun Feb 10 21:32:34 2013 +++ fsck_ffs.8 Sun Feb 10 21:39:17 2013 @@ -304,4 +304,5 @@ are fully enumerated and explained in Appendix A of .Xr growfs 8 , .Xr mount_ffs 8 , .Xr newfs 8 , +.Xr scan_ffs 8 , .Xr rc 8 -- Scott McEachern https://www.blackstaff.ca
Re: faithd fcntl diff
On Mon, Feb 11, 2013 at 05:00:08PM +0100, Mark Kettenis wrote: Date: Mon, 11 Feb 2013 00:05:29 -0600 From: Todd T. Fries t...@fries.net In light of nat64 in pf(4), what purpose does faithd(8) serve anymore? I played with it a bit over a decade ago, but don't recall having any use for it in the last number of years. I vote it gets tedu'ed. I fear it's too late in the game to do that now. Bring this up again after unlock. Meanwhile, perhaps that bug (if it really is a bug) should be fixed? yeah, I'd probably shy away from tedu'ing it at this late stage in the release cycle - make sure it's adequate for release, and then get your inner ted out as soon as the tree unlocks after release...
Re: usermod: lock/unlock local password
Antoine Jacoutot wrote: This diff adds 2 new options to usermod(8): -U to unlock a user's password -Z to lock a user's password Today I was working with these two switches and really got confused. I've tested the following with snapshots from Jan 11 and 5.3-beta. I've got a user with 13 asterisks in the password field as described in passwd(5): test:*:1002:1002::0:0:,,,:/home/test:/bin/ksh After locking the account with usermod -Z test: test:*:1002:1002::0:0:,,,:/home/test:/bin/ksh- After unlocking the account with usermod -U test: test::1002:1002::0:0:,,,:/home/test:/bin 1) The login shell is broken. 2) The password field consists of 12 asterisks. I'd expect it to be just the same as it was before unlocking the account. This propably makes security(8) complain, and more importantly, it never adds an asterisk when locking but always removes an asterisk when unlocking, so the account would be accessible without a password after some lock-unlock cycles (at least the shell is still broken): test::1002:1002::0:0:,,,:/home/test:/bin Can't tell if this problem relates to users with normal password authentication. I did only test users with 13 asterisks in the password field. Regards André
Re: usermod: lock/unlock local password
On Mon, Feb 11, 2013 at 10:11:25PM +0100, André Stöbe wrote: Antoine Jacoutot wrote: This diff adds 2 new options to usermod(8): -U to unlock a user's password -Z to lock a user's password Today I was working with these two switches and really got confused. I've tested the following with snapshots from Jan 11 and 5.3-beta. I've got a user with 13 asterisks in the password field as described in passwd(5): test:*:1002:1002::0:0:,,,:/home/test:/bin/ksh After locking the account with usermod -Z test: test:*:1002:1002::0:0:,,,:/home/test:/bin/ksh- After unlocking the account with usermod -U test: test::1002:1002::0:0:,,,:/home/test:/bin 1) The login shell is broken. 2) The password field consists of 12 asterisks. I'd expect it to be just the same as it was before unlocking the account. This propably makes security(8) complain, and more importantly, it never adds an asterisk when locking but always removes an asterisk when unlocking, so the account would be accessible without a password after some lock-unlock cycles (at least the shell is still broken): test::1002:1002::0:0:,,,:/home/test:/bin Can't tell if this problem relates to users with normal password authentication. I did only test users with 13 asterisks in the password field. I'll have a look. -- Antoine
Re: usermod: lock/unlock local password
On Mon, Feb 11, 2013 at 10:57:46PM +0100, Antoine Jacoutot wrote: On Mon, Feb 11, 2013 at 10:11:25PM +0100, André Stöbe wrote: Antoine Jacoutot wrote: This diff adds 2 new options to usermod(8): -U to unlock a user's password -Z to lock a user's password Today I was working with these two switches and really got confused. I've tested the following with snapshots from Jan 11 and 5.3-beta. I've got a user with 13 asterisks in the password field as described in passwd(5): test:*:1002:1002::0:0:,,,:/home/test:/bin/ksh After locking the account with usermod -Z test: test:*:1002:1002::0:0:,,,:/home/test:/bin/ksh- After unlocking the account with usermod -U test: test::1002:1002::0:0:,,,:/home/test:/bin 1) The login shell is broken. 2) The password field consists of 12 asterisks. I'd expect it to be just the same as it was before unlocking the account. This propably makes security(8) complain, and more importantly, it never adds an asterisk when locking but always removes an asterisk when unlocking, so the account would be accessible without a password after some lock-unlock cycles (at least the shell is still broken): test::1002:1002::0:0:,,,:/home/test:/bin Can't tell if this problem relates to users with normal password authentication. I did only test users with 13 asterisks in the password field. I'll have a look. OK, I was reading passwd(5) and now I'm asking myself - why the hell do daemons from ports have 13 asterisks in password field (base daemons just have single asterisk)? _tor:*:566:566:daemon:0:0:tor:/nonexistent:/sbin/nologin This is obviously not intended to be an account for logging in even via some other authentication methods. jirib
Re: Detect on-die temp sensor for Atom E6xx on amd64
On Wednesday 30 January 2013 3:49:34 am Mark Kettenis wrote:
Date: Tue, 29 Jan 2013 17:35:13 -0500
From: Matt Dainty m...@bodgit-n-scarper.com
* Christian Weisgerber na...@mips.inka.de [2013-01-24 13:03:43]:
I think it's dubious that we match the CPU brand name for this at
all. Shouldn't this be properly handled with CPUID?
Here's a slightly simpler diff that checks the vendor rather than the
CPU brand.
I'm not sure if it's safe to check CPUID regardless of vendor, plus
there is the CLFLUSH code in that block as well, I figure that's
confined to Intel for a reason?
Look at the equivalent i386 code.
Looking at the the equivalent i386 code shows that ci_cflushsz is
only set when the vendor is Intel and the cpu features has CFLUSH
set. Also core update sensors are only checked when vendor is
Intel and cpuid_level = 0x06. The following diff changes amd64
to follow these rules, allows the Atom E6XX sensors to attach and
brings amd64 closer to i386 for these items.
-Kurt
Index: sys/arch/amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.43
diff -u -p -r1.43 identcpu.c
--- sys/arch/amd64/amd64/identcpu.c 10 Nov 2012 09:45:05 - 1.43
+++ sys/arch/amd64/amd64/identcpu.c 12 Feb 2013 04:21:35 -
@@ -506,20 +506,24 @@ identifycpu(struct cpu_info *ci)
if (ci-ci_feature_sefflags SEFF0EBX_SMAP)
replacesmap();
}
- if (!strncmp(mycpu_model, Intel, 5)) {
- u_int32_t cflushsz;
+ if (!strcmp(cpu_vendor, GenuineIntel)) {
+ if (ci-ci_feature_flags CPUID_CFLUSH) {
+ u_int32_t cflushsz;
- CPUID(0x01, dummy, cflushsz, dummy, dummy);
- /* cflush cacheline size is equal to bits 15-8 of ebx * 8 */
- ci-ci_cflushsz = ((cflushsz 8) 0xff) * 8;
- CPUID(0x06, val, dummy, dummy, dummy);
- if (val 0x1) {
- strlcpy(ci-ci_sensordev.xname, ci-ci_dev-dv_xname,
- sizeof(ci-ci_sensordev.xname));
- ci-ci_sensor.type = SENSOR_TEMP;
- sensor_task_register(ci, intelcore_update_sensor, 5);
- sensor_attach(ci-ci_sensordev, ci-ci_sensor);
- sensordev_install(ci-ci_sensordev);
+ CPUID(0x01, dummy, cflushsz, dummy, dummy);
+ /* cflush cacheline size is equal to bits 15-8 of ebx *
8 */
+ ci-ci_cflushsz = ((cflushsz 8) 0xff) * 8;
+ }
+ if (cpuid_level = 0x06) {
+ CPUID(0x06, val, dummy, dummy, dummy);
+ if (val 0x1) {
+ strlcpy(ci-ci_sensordev.xname,
ci-ci_dev-dv_xname,
+ sizeof(ci-ci_sensordev.xname));
+ ci-ci_sensor.type = SENSOR_TEMP;
+ sensor_task_register(ci,
intelcore_update_sensor, 5);
+ sensor_attach(ci-ci_sensordev,
ci-ci_sensor);
+ sensordev_install(ci-ci_sensordev);
+ }
}
}
