Re: md5: new -C flag to skip non-existent files in checklist

2012-03-12 Thread Daniel C. Sinclair
What do you think of making cksum output:

(SHA256) nonexistant.txt: MISSING

instead of FAILED and the extra output to stderr saying No such file
or directory?

This would make it easier to ignore the MISSING files but still see
those that FAILED the checksum.


On Thu, Feb 23, 2012 at 12:24 PM, Lawrence Teo wrote:
 On Thu, Feb 23, 2012 at 11:46:11AM +0100, Mark Kettenis wrote:
  Date: Thu, 23 Feb 2012 10:48:17 +0100
  From: Marc Espie
  On Thu, Feb 23, 2012 at 08:16:20AM +, Nicholas Marriott wrote:
   Is this really much more useful than 2/dev/null?
  Note the FAILED that vanish.
  I'm not sure it's not bloat anyways.

 None of the other BSDs seem to implement an option like this (and
 md5(1) is pretty much a BSDism; Linux and Solaris don't have it).

 Our policy tends to be to not add non-standard options to our
 utilities to encourage people to write portable shell scripts.  Of
 course we make exceptions if a strong case can be made for the added
 functionality.  But personally I don't think that's the case here.

 md5(1) on FreeBSD, DragonFly BSD, and OS X do not even have -c, so in a
 way shell scripts with md5 -c are already relatively unportable. :)

 I do appreciate your feedback and understand your point.


Re: rdate no longer syncs on boot

2011-07-18 Thread Daniel C. Sinclair
On Mon, Jul 18, 2011 at 9:11 AM, Theo de Raadt wrote:

 No thanks.

 I talked with a few people like this, and people who want to use rdate should
 be using it as rdate -n probably, and in that case, they should use ntpd -s

I find rdate_flags useful on my work laptop - I usually boot at my
desk while connected to the network where our internal ntp servers
are.  It syncs, and then I take the laptop out to other
locations/networks where ntp is not accessible.  Running ntpd isn't
useful then and I would have to kill it after it set the time.  I
could run rdate manually after boot but the clock jumps.

How do other people keep correct time on their laptops when access to
ntp servers is intermittent?

 rdate is not a daemon.

Yeah, at first I didn't want to special-case it in /etc/rc and using
an rc.d script allowed it to nicely fit in at the right time during
boot.  How about this instead:

Index: rc
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.385
diff -u -r1.385 rc
--- rc  11 Jul 2011 17:20:09 -  1.385
+++ rc  19 Jul 2011 00:53:49 -
@@ -415,7 +415,14 @@

 echo -n 'starting early daemons:'
-start_daemon syslogd ldattach pflogd named nsd ntpd isakmpd iked sasyncd
+start_daemon syslogd ldattach pflogd named nsd
+# run rdate before ntpd
+if [ X${rdate_flags} != XNO ]; then
+echo -n ' rdate';   rdate -s ${rdate_flags}
+start_daemon ntpd isakmpd iked sasyncd
 echo '.'

 if [ X${ipsec} != XNO ]; then

I think it is a useful feature and like you said there are others that
think the same.  I'd hate to see it go.


Re: rdate no longer syncs on boot

2011-07-18 Thread Daniel C. Sinclair
On Mon, Jul 18, 2011 at 6:31 PM, Theo de Raadt
 There is ntp everywhere.  Use:

 server myownmachine.mynetwork.xx

I often plug this laptop in to unknown stuff (or mirror/span ports or
ethernet taps) and run tcpdump so I don't want to run any daemons that
generate traffic.  It's a little netbook and I use it for network
troubleshooting only - it isn't a normal laptop setup.  My main laptop
does run ntpd all the time though.

I guess I will just use ntpd from now on and manually stop it if
needed.  Of course, with ntpd_flags=-s in my rc.conf.local I won't
be able to start it again without jumping the clock.

What do you think of making -s the default in /etc/rc.d/ntpd so it
always syncs during boot but not any subsequent manual
starts/restarts?  Then one would just use ntpd_flags= in
rc.conf.local (or -S to disable the auto sync if desired).  If ntpd
crashed on a server the only way to safely start it again would be to
reboot (or run ntpd directly but that negates the whole point of

 Running ntpd isn't
 useful then and I would have to kill it after it set the time.  I
 could run rdate manually after boot but the clock jumps.

 That is why you should not run rdate.

ntpd -s does exactly the same thing.  Clock jumps are fine during boot.

 The diff you supplied is exactly what I deleted previously.  No.

Since rdate_flags was left in rc.conf, I thought the removal may have
been an oversight.


new usb quirk and gps device id that needs it

2011-02-09 Thread Daniel C. Sinclair
Hello, I recently got a Qstarz BT-Q818XT GPS receiver
( which
contains an MTK vII/3329 chipset
(  I got the
following when I plugged it into my laptop which is running
yesterday's snapshot:

umodem0 at uhub1 port 2 configuration 1 interface 1 MTK GPS Receiver
rev 2.00/1.00 addr 2
umodem0: no pointer to data interface
ugen0 at uhub1 port 2 configuration 1 MTK GPS Receiver rev 2.00/1.00 addr 2

I came up with some patches that make my GPS work and now I get the following:

umodem0 at uhub1 port 2 configuration 1 interface 1 MTK GPS Receiver
rev 2.00/1.00 addr 2
umodem0: data interface 0, has no CM over data, has no break
umodem0: status change notification available
ucom0 at umodem0

The first patch adds a new class of USB quirks:

Index: usb_quirks.h
RCS file: /cvs/src/sys/dev/usb/usb_quirks.h,v
retrieving revision 1.16
diff -u -r1.16 usb_quirks.h
--- usb_quirks.h19 Jul 2010 05:08:37 -  1.16
+++ usb_quirks.h10 Feb 2011 01:37:18 -
@@ -49,6 +49,7 @@
 #define UQ_MS_LEADING_BYTE 0x0001 /* mouse sends unknown leading byte 
 #define UQ_EHCI_NEEDTO_DISOWN  0x0002 /* must hand device over to USB 1.1
if attached to EHCI */
+#define UQ_NO_CDC_UNION0x0004 /* no CDC UNION descriptor */

 extern const struct usbd_quirks usbd_no_quirk;
Index: umodem.c
RCS file: /cvs/src/sys/dev/usb/umodem.c,v
retrieving revision 1.41
diff -u -r1.41 umodem.c
--- umodem.c25 Jan 2011 20:03:36 -  1.41
+++ umodem.c10 Feb 2011 01:37:18 -
@@ -267,10 +267,13 @@
/* Get the capabilities. */
umodem_get_caps(uaa, id-bInterfaceNumber, data_iface_no,
sc-sc_cm_cap, sc-sc_acm_cap);
-   if (data_iface_no == 0) {
-   printf(%s: no pointer to data interface\n,
-  sc-sc_dev.dv_xname);
-   goto bad;
+   if (!(usbd_get_quirks(sc-sc_udev)-uq_flags  UQ_NO_CDC_UNION)) {
+   if (data_iface_no == 0) {
+   printf(%s: no pointer to data interface\n,
+  sc-sc_dev.dv_xname);
+   goto bad;
+   }

printf(%s: data interface %d, has %sCM over data, has %sbreak\n,

The second patch adds the vendor/device IDs and makes the GPS use the quirk:

Index: usbdevs
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.540
diff -u -r1.540 usbdevs
--- usbdevs 1 Feb 2011 18:23:59 -   1.540
+++ usbdevs 10 Feb 2011 01:37:53 -
@@ -437,6 +437,7 @@
 vendor HAWKING 0x0e66  Hawking
 vendor FOSSIL  0x0e67  Fossil
 vendor GMATE   0x0e7e  G.Mate
+vendor MTK 0x0e8d  MTK
 vendor OTI 0x0ea0  Ours Technology
 vendor PILOTECH0x0eaf  Pilotech
 vendor NOVATECH0x0eb0  Nova Tech
@@ -2565,6 +2566,9 @@

 /* MDS products */
 product MDS ISDBT  0x0001  MDS ISDB-T tuner
+/* MTK products */
+product MTK VII33290x3329  vII/3329 GPS Receiver

 /* Meinberg Funkuhren products */
 product MEINBERG USB5131   0x0301  USB 5131 DCF77 - Radio Clock
Index: usb_quirks.c
RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
retrieving revision 1.63
diff -u -r1.63 usb_quirks.c
--- usb_quirks.c2 Dec 2010 06:39:09 -   1.63
+++ usb_quirks.c10 Feb 2011 01:37:54 -
@@ -133,6 +133,8 @@


A very similar thing was done in NetBSD last year.  See


Re: sync adduser with installer

2010-10-30 Thread Daniel C. Sinclair
On Fri, Oct 29, 2010 at 10:12 PM, Brynet wrote:

 I believe the real problem here is that you're allowing users on your
 systems that are incapable of properly setting the group/world
 permissions of their home directories.

My employer lets a variety of people on their systems - they just want
work to get done and don't know or care about this kind of thing.
Don't you have this problem where you work?

Seriously, putting everyone in the same 'users' group is like running
all your daemons as 'nobody'.  I can quote a stack of UNIX books that
recommend against both (a couple examples are Secure Architectures
with OpenBSD, the AbsoluteBSD books, and the ones I linked to above).
They all talk about using 'adduser' and how per-user groups is the
best option - which is why it is the default.  Changing the default
would invalidate a lot of documentation.

 It's also a possibility that you are derelict in your duties as a
 systems administrator.

 No cookies for you.

This is tech@, not m...@.


Re: sync adduser with installer

2010-10-29 Thread Daniel C. Sinclair
On Fri, Oct 29, 2010 at 11:25 AM, Henning Brauer wrote:
 * Philip Guenther [2010-10-29 19:48]:

 Group-per-user setups solve this by letting people safely have a umask
 of 007 or 002.  When they do work in a directory whose group is a
 secondary group, the resulting files are (and stay) writable by the
 group**.  Permitting that change in default umask eliminates the
 requirement for manual changes and their cognitive load as the user
 moves between projects and directories.  Fewer forgets and mistakes
 meant fewer emails to root asking for me to fix the perms on some file
 while so-and-so was on vacation, etc.

 I have to agree here.

Same here.  Really, I'm surprised that anyone is using the 'users'
group at all these days, especially on OpenBSD.  If all users are in
the same group, group permissions are no different from world

The book Mastering FreeBSD and OpenBSD security talks about per-user
groups being the best option here:

Add the FreeBSD manual here:

useradd/del/mod/info were meant to be low-level tools for scripts to
use.  adduser and rmuser are higher-level and can be used
interactively.  rmuser for example removes a users cron/at jobs and
/var/mail file and adduser can send a welcome email to the user -
userdel/add don't.

I don't add users with the OpenBSD installer because it does the wrong
thing and should be fixed to use the adduser defaults.  :)


wdc patch to get SSD with native SATA working on HP2133 netbook

2009-07-03 Thread Daniel C. Sinclair
As detailed in the following link I have to disable pciide and set my
BIOS to use SATA drives in 'compatible' mode in order to use my HP2133
netbook with the cheap 4GB SSD it came with:

I looked into the problem and discovered that my drive only supports
Ultra-DMA mode 4.  The pciide/wdc code forces various PIO/DMA settings
(including UDMA5) when it detects a SATA drive in 'native' mode and
dispenses with any autodetection.  The following patch just removes
the forced settings and lets the autodetection run.  My drive is
detected properly with my BIOS set to use native SATA and runs at a
more acceptable speed.  Presumably someone added that code because
some drives don't work with autodetection so I doubt this patch can be
applied to 4.6-beta without more widespread testing.


Index: wdc.c
RCS file: /cvs/src/sys/dev/ic/wdc.c,v
retrieving revision 1.102
diff -u wdc.c
--- wdc.c   7 Feb 2009 08:07:28 -   1.102
+++ wdc.c   4 Jul 2009 00:41:43 -
@@ -1245,21 +1245,6 @@
   int i, valid_mode_found;
   int cf_flags = drvp-cf_flags;

-   if ((wdc-cap  WDC_CAPABILITY_SATA) != 0 
-   (params-atap_sata_caps != 0x 
-   params-atap_sata_caps != 0x)) {
-   WDCDEBUG_PRINT((%s: atap_sata_caps=0x%x\n, __func__,
-   params-atap_sata_caps), DEBUG_PROBE);
-   /* Skip ATA modes detection for native SATA drives */
-   drvp-PIO_mode = drvp-PIO_cap = 4;
-   drvp-DMA_mode = drvp-DMA_cap = 2;
-   drvp-UDMA_mode = drvp-UDMA_cap = 5;
-   drvp-drive_flags |= DRIVE_SATA | DRIVE_MODE | DRIVE_UDMA;
-   drvp-ata_vers = 4;
-   return;
-   }
   if ((wdc-cap  (WDC_CAPABILITY_DATA16 | WDC_CAPABILITY_DATA32)) ==
   struct ataparams params2;

diff of dmesg before patch (with SATA in compatible mode) and after
(with SATA in native mode):

--- dmesg.beforeFri Jul  3 17:16:14 2009
+++ dmesg.after Fri Jul  3 17:19:11 2009
@@ -1,112 +1,106 @@
-OpenBSD 4.6-beta (GENERIC) #37: Tue Jun 30 11:13:06 MDT 2009
+OpenBSD 4.6 (build) #1: Fri Jul  3 17:05:05 PDT 2009
 cpu0: VIA C7-M Processor 1000MHz (CentaurHauls 686-class) 1 GHz
 real mem  = 1877241856 (1790MB)
 avail mem = 1805881344 (1722MB)
-User Kernel Config
-UKC disable pciide
-105 pciide* disabled
-106 pciide* disabled
-UKC quit
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 11/11/08, BIOS32 rev. 0 @
0xf0010, SMBIOS rev. 2.5 @ 0xfc590 (19 entries)
 bios0: vendor Hewlett-Packard version 68VGU Ver. F.06 date 11/11/2008
 bios0: Hewlett-Packard HP 2133
 acpi0 at bios0: rev 2
 acpi0: wakeup devices BLAN(S0) SLPB(S4)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: apic clock running at 99MHz
 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 3, 24 pins
 ioapic1 at mainbus0: apid 2 pa 0xfecc, version 3, 24 pins
 acpihpet0 at acpi0: 14318179 Hz
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 1 (P0P1)
 acpiprt2 at acpi0: bus 2 (NBPG)
 acpiprt3 at acpi0: bus 0 (P0P9)
 acpiprt4 at acpi0: bus 7 (P0PA)
 acpiprt5 at acpi0: bus 5 (NBP0)
 acpiprt6 at acpi0: bus 128 (PCI1)
 acpiec0 at acpi0
 acpicpu0 at acpi0: C3, C2, PSS
 acpipwrres0 at acpi0: APMF
 acpitz0 at acpi0: critical temperature 105 degC
 acpiac0 at acpi0: AC unit online
 acpibat0 at acpi0: BAT1 model Primary serial 10 type LiOn oem
 acpibtn0 at acpi0: LID_
 acpibtn1 at acpi0: SLPB
 acpibtn2 at acpi0: PWRB
 acpivideo0 at acpi0: VGA_
 acpivout0 at acpivideo0: LCD_
 acpivout1 at acpivideo0: CRT_
 bios0: ROM list: 0xc/0xcc00
 cpu0: Enhanced SpeedStep 998 MHz: speeds: 1000, 800, 600, 400 MHz
 pci0 at mainbus0 bus 0: configuration mode 1 (bios)
 pchb0 at pci0 dev 0 function 0 VIA P4M900 Host rev 0x00
 viaagp0 at pchb0: v3
 agp0 at viaagp0: aperture at 0xf000, size 0x1000
 pchb1 at pci0 dev 0 function 1 VIA P4M900 Host rev 0x00
 pchb2 at pci0 dev 0 function 2 VIA P4M900 Host rev 0x00
 pchb3 at pci0 dev 0 function 3 VIA P4M900 Host rev 0x00
 pchb4 at pci0 dev 0 function 4 VIA P4M900 Host rev 0x00
 VIA P4M900 IOAPIC rev 0x00 at pci0 dev 0 function 5 not configured
 pchb5 at pci0 dev 0 function 6 VIA P4M900 Security rev 0x00
 pchb6 at pci0 dev 0 function 7 VIA P4M900 Host rev 0x00
 ppb0 at pci0 dev 1 function 0 VIA VT8377 AGP rev 0x00
 pci1 at ppb0