install.sub - disklabel template modification
Hi,
if somebody would put into install.conf following line:
URL to autopartitioning template for disklabel = /disklabel.template
ftp would end in its prompt.
# ftp -Vo - /disklabel.template
ftp: /disklabel.template: no address associated with name
ftp>
I took current check for ramdisk local {install,upgrade}.conf
649:[[ -f $_rf ]] && _rf="file://$_rf"
and added it to disklabel_autolayout(), so installer would know
how to handle path to ramdisk's local disklabel template without file:// uri.
Jiri
---%>---
diff --git distrib/miniroot/install.sub distrib/miniroot/install.sub
index 740064a86a8..63ecf5cab14 100644
--- distrib/miniroot/install.sub
+++ distrib/miniroot/install.sub
@@ -414,6 +414,7 @@ disklabel_autolayout() {
err_exit "https not supported on this platform."
fi
echo "Fetching $resp"
+ [[ -f $resp ]] && resp="file://$resp"
if unpriv ftp -Vo - "$resp" >$_dl && [[ -s $_dl ]]; then
disklabel -T $_dl -F $_f -w -A $_disk && return
err_exit "Autopartitioning failed."
---%<---
Re: drm: DP update that fixes T460 external monitors through docks
On Wed, Feb 21, 2018 at 03:30:13PM +0200, Paul Irofti wrote:
> For the archives, here is a diff that fixes a locking warning with the
> earlier patch. So you have to apply it after the former one.
>
> diff --git sys/dev/pci/drm/drm_probe_helper.c
> sys/dev/pci/drm/drm_probe_helper.c
> index 936c0c1d3a7..84a0e585d32 100644
> --- sys/dev/pci/drm/drm_probe_helper.c
> +++ sys/dev/pci/drm/drm_probe_helper.c
> @@ -136,15 +136,27 @@ static int
> drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
> struct drm_display_mode *mode;
> const struct drm_connector_helper_funcs *connector_funcs =
> connector->helper_private;
> - int count = 0;
> + int count = 0, ret;
> int mode_flags = 0;
> bool verbose_prune = true;
> enum drm_connector_status old_status;
> + struct drm_modeset_acquire_ctx ctx;
>
> WARN_ON(!mutex_is_locked(>mode_config.mutex));
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> connector->name);
> +
> + drm_modeset_acquire_init(, 0);
> +
> +retry:
> + ret = drm_modeset_lock(>mode_config.connection_mutex, );
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff();
> + goto retry;
> + } else
> + WARN_ON(ret < 0);
> +
> /* set all modes to the unverified state */
> list_for_each_entry(mode, >modes, head)
> mode->status = MODE_UNVERIFIED;
> @@ -248,6 +260,9 @@ static int
> drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
> prune:
> drm_mode_prune_invalid(dev, >modes, verbose_prune);
>
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
> if (list_empty(>modes))
> return 0;
>
>
I'm using it daily for couple of days, FDE and hibernating.
Although I still see some 'error's and 'WARNING's, see below:
OpenBSD 6.2-current (GENERIC.MP) #0: Fri Feb 23 22:40:24 CET 2018
ji...@t470s.example.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17032802304 (16243MB)
avail mem = 16509616128 (15744MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x9a2bb000 (62 entries)
bios0: vendor LENOVO version "N1WET41W (1.20 )" date 10/17/2017
bios0: LENOVO 20HGS22D0W
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT BOOT
BATB SSDT SSDT SSDT WSMT SSDT SSDT DBGP DBG2 POAT DMAR ASF! FPDT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) RP02(S4)
RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) RP09(S4) RP10(S4) RP11(S4)
RP12(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz, 2694.93 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz, 2693.74 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz, 2693.73 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz, 2693.74 MHz
cpu3:
Re: less(1): `!' command
On Sat, Dec 16, 2017 at 04:55:44PM +, kshe wrote: > Hi, > > Would a patch to bring back the `!' command to less(1) be accepted? The > commit message for its removal explains that ^Z should be used instead, > but that obviously does not work if less(1) is run from something else > than an interactive shell, for example when reading manual pages from a > vi(1) instance spawned directly by `xterm -e vi' in a window manager or > by `neww vi' in a tmux(1) session. Why should less be able to spawn another programs? This would undermine all pledge work. IIUC your vi scenario, you are not spawing 'vi' from less but the opposite way. That should work. j.
Re: diff for ssh/sftp/scp -j
On Sat, Nov 25, 2017 at 11:16:54PM +0100, Holger Mikolon wrote: > Hi tech@ > > at work I can ssh (hence cvs) to public servers only via a ProxyCommand > specified in /etc/ssh/ssh_config. > > However, with the ProxyCommand set I cannot ssh into servers in the > internal network. So I end up changing ssh_config depending on my > use case over and over. This bothered me enough to come up with the > following simple diff. It adds a command line option -j to ssh/sftp/scp > for ignoring the ProxyCommand. Of course "-j" can be changed to any > other free letter. > > Anyone else finding this useful? Comments? > > Regards > Holger > ;-se Wouldn't help you just use wildcards for Host in ssh_config and/or CanonicalizeHostname? Jiri
Re: [patch] Remove local nameservers from dhclient.conf during an upgrade.
On Fri, Sep 08, 2017 at 12:12:09PM +0200, Jesper Wallin wrote:
> Hi all,
>
> I have a local unbound running for caching purposes as well as ensuring
> that my DNS traffic is encrypted, using DNS-over-TLS. This works just
> fine, except for when I try to run the snapshot upgrade process.
>
> The installer will copy my on-disk configuration and try to setup the
> network, using the "supersede domain-name-servers 127.0.0.1;" in my
> /etc/dhclient.conf. This gives me no errors, of course, since nothing
> is wrong with the configuration. But since no nameserver is running on
> localhost, we're unable to resolve hosts. The first indication of this
> is "Unable to connect using https. Use http instead?" which is somewhat
> unclear, as it led me to believe it's an issue with TLS.
>
> Anyway, the patch below will basically try to ignore any local
> nameservers when copying the on-disk configuration. My first approach
> was to check if we could resolve a hostname instead, before givig the
> https error, but seeing that host, dig or nslookup is unavailable, I
> decided to go with this instead.
>
>
> Jesper Wallin
>
>
> Index: distrib/miniroot/install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1035
> diff -u -p -r1.1035 install.sub
> --- distrib/miniroot/install.sub 25 Aug 2017 18:21:30 - 1.1035
> +++ distrib/miniroot/install.sub 8 Sep 2017 09:25:51 -
> @@ -2258,6 +2258,13 @@ enable_network() {
> fi
> done
>
> + # Remove local nameservers since they are unavailable.
> + if [ -f "/etc/dhclient.conf" ]; then
> + cat /etc/dhclient.conf | sed -E \
> + '/supersede +domain-name-servers +.*(127.0.0.1|::1)/d' \
> + > /etc/dhclient.conf
> + fi
^^ if you would append a dns server which it provided by dhcp to your
regular /etc/dhclient.conf, then it should work find, shouldn't it?
it would try first one, fail, try second one.
and your changed doesn't work for servers with do use static ip
settings and have local dns in /etc/resolv.conf. am I not right?
j.
Re: network booting efi systems with dhcpd(8)
> > The ISC dhcpd approach to using this looks something like this:
> >
> > option arch code 93 = unsigned integer 16;
> >
> > if option arch = 00:00 {
> > filename "bios/pxelinux.0";
> > } elsif option arch = 00:07 {
> > filename "efi.x64/syslinux.efi";
> > }
>
> [...] IIUC OpenBSD dhcpd doesn't support conditionals...
Ugly workaround is to use rewrite via tftpd's socket
but one has to known IP address in advance.
-r socket
Issue filename rewrite requests to the specified UNIX domain
socket. tftpd will write lines in the format "IP OP filename",
terminated by a newline, where IP is the client's IP address, and
OP is one of "read" or "write". tftpd expects replies in the
format "filename" terminated by a newline. All rewrite requests
from the daemon must be answered (even if it is with the original
filename) before the TFTP request will continue. By default
tftpd does not use filename rewriting.
j.
Re: network booting efi systems with dhcpd(8)
On Mon, Jan 23, 2017 at 08:39:17PM +1000, Jonathan Matthew wrote:
> For network boot clients, dhcpd(8) can supply a filename for the initial
> boot file for the client, which is something like pxeboot (or pxelinux.0).
> EFI and BIOS clients need different boot files, though, so the server
> needs to know what mode the client is booting in, in order to supply the
> right filename. RFC 4578 defines DHCP client option 93 for this purpose.
>
> The ISC dhcpd approach to using this looks something like this:
>
> option arch code 93 = unsigned integer 16;
>
> if option arch = 00:00 {
> filename "bios/pxelinux.0";
> } elsif option arch = 00:07 {
> filename "efi.x64/syslinux.efi";
> }
>
> which seems a bit complicated, and also a lot of work to implement. Instead
> I propose adding 'efi-filename' (and 'efi32-filename', though I'm not sure
> that's worth doing) next to the existing 'filename' statement and having
> dhcpd itself interpret the option values to figure out which one should be
> used.
'filename' or 'option bootfile-name' are used by autoinstall. I'm not
sure diverting dhcpd option for boot image from rest of world is good
way. IIUC OpenBSD dhcpd doesn't support conditionals...
j.
[ftp] missing new line in debug+verbose mode
See 'GET /url...' location in the output in the first example:
j.
$ ftp -o /dev/null -M -d http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/
host ftp.eu.openbsd.org, port (null), path pub/OpenBSD/snapshots/amd64/, save
as /dev/null, auth (null).
Trying 77.238.36.16...
Requesting http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/GET
/pub/OpenBSD/snapshots/amd64/ HTTP/1.0
Host: ftp.eu.openbsd.org
User-Agent: OpenBSD ftp
received 'HTTP/1.1 200 OK'
received 'Date: Thu, 08 Dec 2016 18:06:35 GMT'
received 'Server: Apache/2.2.22 (Ubuntu)'
received 'Vary: Accept-Encoding'
received 'Content-Length: 6018'
received 'Connection: close'
received 'Content-Type: text/html;charset=UTF-8'
6018 bytes received in 0.01 seconds (670.27 KB/s)
$ ftp -o /dev/null -M -d -V
http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/
host ftp.eu.openbsd.org, port (null), path pub/OpenBSD/snapshots/amd64/, save
as /dev/null, auth (null).
GET /pub/OpenBSD/snapshots/amd64/ HTTP/1.0
Host: ftp.eu.openbsd.org
User-Agent: OpenBSD ftp
received 'HTTP/1.1 200 OK'
received 'Date: Thu, 08 Dec 2016 18:06:44 GMT'
received 'Server: Apache/2.2.22 (Ubuntu)'
received 'Vary: Accept-Encoding'
received 'Content-Length: 6018'
received 'Connection: close'
received 'Content-Type: text/html;charset=UTF-8'
Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.149
diff -u -p -u -p -r1.149 fetch.c
--- fetch.c 20 Aug 2016 20:18:42 - 1.149
+++ fetch.c 8 Dec 2016 18:16:44 -
@@ -625,7 +625,7 @@ noslash:
#endif /* !SMALL */
if (verbose)
- fprintf(ttyout, "Requesting %s", origline);
+ fprintf(ttyout, "Requesting %s\n", origline);
/*
* Construct and send the request. Proxy requests don't want leading /.
$ /home/jirib/cvs/openbsd-src/usr.bin/ftp/obj/ftp -o /dev/null -M -d
http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/
host ftp.eu.openbsd.org, port (null), path pub/OpenBSD/snapshots/amd64/, save
as /dev/null, auth (null).
Trying 77.238.36.56...
Requesting http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/
GET /pub/OpenBSD/snapshots/amd64/ HTTP/1.0
Host: ftp.eu.openbsd.org
User-Agent: OpenBSD ftp
received 'HTTP/1.1 200 OK'
received 'Date: Thu, 08 Dec 2016 18:10:51 GMT'
received 'Server: Apache/2.2.22 (Ubuntu)'
received 'Vary: Accept-Encoding'
received 'Content-Length: 6018'
received 'Connection: close'
received 'Content-Type: text/html;charset=UTF-8'
6018 bytes received in 0.00 seconds (49.48 MB/s)
And comparison with curl:
$ curl -i -v -o /dev/null -s
http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/
* Trying 77.238.36.56...
* TCP_NODELAY set
* Connected to ftp.eu.openbsd.org (77.238.36.56) port 80 (#0)
> GET /pub/OpenBSD/snapshots/amd64/ HTTP/1.1
> Host: ftp.eu.openbsd.org
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 08 Dec 2016 18:25:18 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Vary: Accept-Encoding
< Content-Length: 6018
< Content-Type: text/html;charset=UTF-8
<
{ [2724 bytes data]
* Curl_http_done: called premature == 0
* Connection #0 to host ftp.eu.openbsd.org left intact
Re: UEFI install fails on Hetzner EX51
On Wed, Nov 23, 2016 at 03:29:55PM +0100, Leo Unglaub wrote: > Hey, > > On 11/23/16 15:17, Mark Kettenis wrote: > >Right, something like that would work if you copy the OpenBSD EFI > >bootloader into /EFI/OpenBSD/BOOTX64.EFI on the EFI system partition > >first. > > why do i have to copy the EFI file first? Does the order matter? > > If yes, the correct workflow would be the following; > > 1: Install OpenBSD > 2: Start a Live-Linux image > 3: Write the UEFI entry with efibootmgr > 4: Reboot and hope the best :) > > Or does someone have a better suggestion? What about efibootmgr, is it worth > importing it into the OpenBSD source tree? Or do you guys want to do it > yourself and create something like a uefictl with a clean CLI to manage UEFI > corrcetly. I am not sure what the best way to go is here, but UEFI is not > going away and the people using it are only going to get more and more do to > larger discs becoming more common. > > Greetings > Leo > Just a note, people could run UEFI VM inside qemu on OpenBSD. See https://github.com/tianocore/tianocore.github.io/wiki/How-to-run-OVMF I only installed OpenBSD inside qemu with OVMF on OpenBSD and at least it booted fine. j.
Re: UEFI install fails on Hetzner EX51
On Wed, Nov 23, 2016 at 01:55:59PM +0100, Leo Unglaub wrote:
> Hey,
>
> On 11/23/16 13:27, Mark Kettenis wrote:
> >>> Booting the UEFI version of the install.fs works fine and also the
> >>> install works but i am unable to boot the server. According the the
> >>> datacenter this happens because OpenBSD does not write an entry in the
> >>> mainboards firmware UEFI bootlist and simply asumes a fallback to
> >>> /boot/bootx64.efi. But according to the datacenter this mainboard does
> >>> not have that fallback and simply does not know what to boot.
> >That sounds correct.
So probably something like this?
efibootmgr --create --disk /dev/$disk --part 1 --label "OpenBSD (${disk})"
--load "\\EFI\\openbsd\\BOOTX64.EFI"
Not tested, I haven't played with OpenBSD on a UEFI machine. I was only
messing with EFI on EL7.
efibootmgr | egrep 'Red Hat Enterprise Linux|^BootOrder|^BootCurrent'
BootCurrent: 0015
BootOrder:
0015,0014,0013,0012,0007,,0002,0001,0005,0006,0008,0009,000A,000B,000C,000D,000E,000F,0010
Boot0012* Red Hat Enterprise Linux
Boot0013* Red Hat Enterprise Linux (sdb)
Boot0014* Red Hat Enterprise Linux (sdc)
Boot0015* Red Hat Enterprise Linux (sdd)
# above shows the system was boot from "alternative" disk (sdd)
j.
Re: Improve error message in rcctl(8)
Could a change solve also this annoying situations? (saved files by editors...) # rcctl ls all | grep ^tor tor tor_2 tor_2~ j.
Re: [file] file -i doesn't detect epub correctly
Thanks to all, `xdg-mime query filetype $epub' works fine now. j.
Re: [PATCH] No comic sans in httpd status pages
Instead of hipster design headache, there's for example this diff which could bring something interesting to httpd http://marc.info/?l=openbsd-tech=144767899506855=2 (httpd URL rewrite support patch) Something like this could make wordpress, drupal, mediawiki users more happy with OpenBSD httpd. j.
Re: ugenctl for attaching USB devices to ugen instead of their specific driver
On Sun, Dec 06, 2015 at 05:23:22PM +, Stuart Henderson wrote: > The bigger problem is "dual use" devices; e.g. some want UPS to attach > to upd(4), others want ugen(4) for use with NUT/apcupsd. Your code is > partially useful for these, but because it just changes things at attach, > won't survive a reboot - if it could instead force a device to detach > and reattach to ugen it would help a lot more cases. I have a question about usb devices which are not as ugen. If I would like to use usb redirection (libusbredir + libusb + spice-gtk) with remote-viewer, part of virt-viewer package, ie. eg. redirecting usb flash disk from laptop to remote Qemu/KVM VM, would I need such usb flash disk be available as ugen? I think so, am I right? IMO mpi@'s point to always present usb devices as well as ugen make sense. j.
Re: ssh-add.1 / ssh-askpass clarification
On Sat, Mar 28, 2015 at 07:19:13AM +, Jason McIntyre wrote: maybe this is clearer: Index: ssh-add.1 === RCS file: /cvs/src/usr.bin/ssh/ssh-add.1,v retrieving revision 1.61 diff -u -r1.61 ssh-add.1 --- ssh-add.1 21 Dec 2014 22:27:56 - 1.61 +++ ssh-add.1 27 Mar 2015 23:21:34 - @@ -88,12 +88,11 @@ .It Fl c Indicates that added identities should be subject to confirmation before being used for authentication. -Confirmation is performed by the -.Ev SSH_ASKPASS -program mentioned below. -Successful confirmation is signaled by a zero exit status from the -.Ev SSH_ASKPASS -program, rather than text entered into the requester. +Confirmation is performed by +.Xr ssh-askpass 1 . +Successful confirmation is signaled by a zero exit status from +.Xr ssh-askpass 1 , +rather than text entered into the requester. .It Fl D Deletes all identities from the agent. .It Fl d @@ -156,6 +155,8 @@ .Ev SSH_ASKPASS are set, it will execute the program specified by .Ev SSH_ASKPASS +(by default +.Dq ssh-askpass ) and open an X11 window to read the passphrase. This is particularly useful when calling .Nm @@ -197,6 +198,7 @@ .Sh SEE ALSO .Xr ssh 1 , .Xr ssh-agent 1 , +.Xr ssh-askpass 1 , .Xr ssh-keygen 1 , .Xr sshd 8 .Sh AUTHORS [...] currently the doc (specifically -c) refers to SSH_ASKPASS. i understand you want to be clear that SSH_ASKPASS does not need to be set, so you added some text to say that explicitly. my diff takes a different approach - it is actually not that common to talk about the environment variable when a sane default exists. usually we document the usual case and in ENVIRONMENT we document the variable that can override defualt behaviour. my diff does that. I'm OK with this. j.
ssh-add.1 / ssh-askpass clarification
Mentioning 'ssh-askpass' is used when SSH_ASKPASS is not set. j. Index: ssh-add.1 === RCS file: /cvs/src/usr.bin/ssh/ssh-add.1,v retrieving revision 1.61 diff -u -p -u -p -r1.61 ssh-add.1 --- ssh-add.1 21 Dec 2014 22:27:56 - 1.61 +++ ssh-add.1 27 Mar 2015 23:04:27 - @@ -152,11 +152,11 @@ If .Nm does not have a terminal associated with it but .Ev DISPLAY -and +is set, it will execute the program specified by .Ev SSH_ASKPASS -are set, it will execute the program specified by -.Ev SSH_ASKPASS -and open an X11 window to read the passphrase. +if not set, by default +.Pa ssh-askpass +, and open an X11 window to read the passphrase. This is particularly useful when calling .Nm from a
Re: ssh-add.1 / ssh-askpass clarification
On Fri, Mar 27, 2015 at 11:22:07PM +, Jason McIntyre wrote: On Fri, Mar 27, 2015 at 07:07:04PM -0400, Jiri B wrote: Mentioning 'ssh-askpass' is used when SSH_ASKPASS is not set. j. Index: ssh-add.1 === RCS file: /cvs/src/usr.bin/ssh/ssh-add.1,v retrieving revision 1.61 diff -u -p -u -p -r1.61 ssh-add.1 --- ssh-add.1 21 Dec 2014 22:27:56 - 1.61 +++ ssh-add.1 27 Mar 2015 23:04:27 - @@ -152,11 +152,11 @@ If .Nm does not have a terminal associated with it but .Ev DISPLAY -and +is set, it will execute the program specified by .Ev SSH_ASKPASS -are set, it will execute the program specified by -.Ev SSH_ASKPASS -and open an X11 window to read the passphrase. +if not set, by default +.Pa ssh-askpass +, and open an X11 window to read the passphrase. This is particularly useful when calling .Nm from a maybe this is clearer: Index: ssh-add.1 === RCS file: /cvs/src/usr.bin/ssh/ssh-add.1,v retrieving revision 1.61 diff -u -r1.61 ssh-add.1 --- ssh-add.1 21 Dec 2014 22:27:56 - 1.61 +++ ssh-add.1 27 Mar 2015 23:21:34 - @@ -88,12 +88,11 @@ .It Fl c Indicates that added identities should be subject to confirmation before being used for authentication. -Confirmation is performed by the -.Ev SSH_ASKPASS -program mentioned below. -Successful confirmation is signaled by a zero exit status from the -.Ev SSH_ASKPASS -program, rather than text entered into the requester. +Confirmation is performed by +.Xr ssh-askpass 1 . +Successful confirmation is signaled by a zero exit status from +.Xr ssh-askpass 1 , +rather than text entered into the requester. .It Fl D Deletes all identities from the agent. .It Fl d @@ -156,6 +155,8 @@ .Ev SSH_ASKPASS are set, it will execute the program specified by .Ev SSH_ASKPASS +(by default +.Dq ssh-askpass ) and open an X11 window to read the passphrase. This is particularly useful when calling .Nm @@ -197,6 +198,7 @@ .Sh SEE ALSO .Xr ssh 1 , .Xr ssh-agent 1 , +.Xr ssh-askpass 1 , .Xr ssh-keygen 1 , .Xr sshd 8 .Sh AUTHORS IIUC the point is SSH_ASKPASS does not need to be set, if not set it falls back to /usr/X11R6/bin/ssh-askpass. But I can be wrong. j.
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote: Using DUIDs in the installed /etc/fstab has been the default for some time now. We'd like to eliminate the question in the installer and just use DUIDs unconditionally. But first we need to know you are aware of any circumstances where people need or prefer to use the non-DUID option when installing? iirc nick@ once said he uses /altroot and thus doesn't use duids. but event it is still the truth it is unusual setup. j.
[DIFF] sftp-server.8, sshd_config.5 after syslog_r change
Hi, is this correct to reflect syslog_r(3) change? I tested chrooted internal-sftp without /dev/log in the chroot and it was logging fine. j. Index: sftp-server.8 === RCS file: /cvs/src/usr.bin/ssh/sftp-server.8,v retrieving revision 1.25 diff -u -p -r1.25 sftp-server.8 --- sftp-server.8 14 Oct 2013 14:18:56 - 1.25 +++ sftp-server.8 18 Jul 2014 20:58:23 - @@ -139,16 +139,6 @@ Sets an explicit to be applied to newly-created files and directories, instead of the user's default mask. .El -.Pp -For logging to work, -.Nm -must be able to access -.Pa /dev/log . -Use of -.Nm -in a chroot configuration therefore requires that -.Xr syslogd 8 -establish a logging socket inside the chroot directory. .Sh SEE ALSO .Xr sftp 1 , .Xr ssh 1 , Index: sshd_config.5 === RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.175 diff -u -p -r1.175 sshd_config.5 --- sshd_config.5 15 Jul 2014 15:54:14 - 1.175 +++ sshd_config.5 18 Jul 2014 20:58:24 - @@ -344,12 +344,7 @@ devices. For file transfer sessions using .Dq sftp , no additional configuration of the environment is necessary if the -in-process sftp server is used, -though sessions which use logging do require -.Pa /dev/log -inside the chroot directory (see -.Xr sftp-server 8 -for details). +in-process sftp server is used. .Pp The default is not to .Xr chroot 2 .
Re: signed packages
On Wed, Jan 22, 2014 at 11:28:50AM +, Stuart Henderson wrote: The model is: only the specific keys placed in /etc/signify are trusted. The plan is to include the public keys used for signing release n+1 in release n. So once you trust a particular key, by verifying signatures on sets which you download+install, you can have a chain of continuity for future keys. You still need to get your initial key from somewhere that you trust. If you are worried about sources of this, you can at least check and compare the 55*.pub files from a few sources e.g. those in downloaded sets against those in anoncvs/cvsweb (cvs -d $CVSROOT get -p src/etc/signify/55base.pub to display on stdout). Of course when the next release is done they'll be on CD. (IIRC somebody suggested printing keys on the tshirts, not sure if print resolution on fabric is really up to that without making the text so big as to be horribly ugly, posters may work though.) Given sufficient space to download tgz before unpacking, the install ramdisk kernel now checks signatures (yes: crypto fits on the ramdisk - signify/ed25519 is small, and yes: please test and report on any problems!). If you're fetching a new installer (ramdisk kernel, install55.iso, floppy*.fs, etc) you can verify the signature of that file before using it. Also it should go without saying, if you use the untar sets on a running system method, checking those sets is your responsibility, see signify(1)'s EXAMPLES section for information about how to do this. What about as TXT record for dns (in combination with DNSSEC) as alternative for getting the key? :) jirib
Re: security(8) check maildir as well as mailbox permissions
On Wed, Dec 18, 2013 at 08:48:38PM +0100, Jérémie Courrèges-Anglas wrote:
skin...@britvault.co.uk (Craig R. Skinner) writes:
On 2013-12-18 Wed 15:54 PM |, Stuart Henderson wrote:
Check the security of /var/mail/dirs similar to /var/mail/boxes:
Indeed, but security(8) really reflects things in the base OS,
smtpd.conf(8)
deliver to maildir path
Mail is added to a maildir. Its location, path, may
contain format specifiers that are expanded before use
Therefore: ... deliver to maildir /var/mail/%{user.username}
Therefore? How so? What's the logic, here?
deliver to maildir path
Mail is added to a maildir. Its location, path, may
contain format specifiers that are expanded before use
(see above). If path is not provided, then ~/Maildir is
assumed.
You're trying to trick people into doing what you want. That's not
a very good idea on this mailing-list.
Maybe a plugin based security(8)? If it won't be accepted into base OS
maybe it could be in ports as an alternative (line base OS nginx with
limited features and nginx in ports).
jirib
[Donation] Processor Freescale P2020 / TL-WDR4900 / Turrir router
Hi, I would like to send TL-WDR4900[1] hardware to a dev for hacking, it's based on Freescale P2020 processor[2] and it should be supported by OpenWRT. Also .cz registrar is developing its own hardware[3] based on Freescale P2020 and one of its policy should be no NDA. Basically it should be similar to TL-WDR4900. If you want this piece, please contact me and I will ship it to you. jirib [1] http://www.tp-link.com/en/products/details/?model=TL-WDR4900 [2] http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P2020 [3] https://www.turris.cz/en/hardware
Re: [Donation] Processor Freescale P2020 / TL-WDR4900 / Turrir router
I would like to send TL-WDR4900[1] hardware to a dev for hacking, it's based on Freescale P2020 processor[2] and it should be supported by OpenWRT. Also .cz registrar is developing its own hardware[3] based on Freescale P2020 and one of its policy should be no NDA. Basically it should be similar to TL-WDR4900. If you want this piece, please contact me and I will ship it to you. jirib [1] http://www.tp-link.com/en/products/details/?model=TL-WDR4900 [2] http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P2020 [3] https://www.turris.cz/en/hardware Just clarification. I do not care about Turrir router software part, but I think more hardware could appear based on Freescale P2020 soon. jirib
apm/zzz/ZZZ ownership
Is it wise to allow every user execute zzz? If apmd
is running this makes machine suspend, works even via
ssh.
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/apm/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile26 Mar 2012 20:17:43 - 1.14
+++ Makefile16 May 2013 18:07:54 -
@@ -18,6 +18,9 @@ LINKS+= ${BINDIR}/apm ${BINDIR}/ZZZ
NOPROG=yes
.endif
+BINOWN= root
+BINGRP= operator
+BINMODE=0550
MAN= apm.8
MANSUBDIR=amd64 i386 loongson macppc sparc sparc64 zaurus
MLINKS=apm.8 zzz.8 apm.8 ZZZ.8
Re: apm/zzz/ZZZ ownership
On Thu, May 16, 2013 at 08:39:41PM +0100, Stuart Henderson wrote:
On 2013/05/16 14:10, Jiri B wrote:
Is it wise to allow every user execute zzz? If apmd
is running this makes machine suspend, works even via
ssh.
restricting the binary permissions is pointless.
restricting the permissions on /var/run/apmdev on the other hand,
would be a good ideaI wonder if someone already thought of that! :-)
Ah, the group is 'wheel' on the socket. One normally doesn't
assign other users to wheel group. So I think it's ok, forget
my previous approach.
jirib
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/apm/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile26 Mar 2012 20:17:43 - 1.14
+++ Makefile16 May 2013 18:07:54 -
@@ -18,6 +18,9 @@ LINKS+= ${BINDIR}/apm ${BINDIR}/ZZZ
NOPROG=yes
.endif
+BINOWN= root
+BINGRP= operator
+BINMODE=0550
MAN= apm.8
MANSUBDIR=amd64 i386 loongson macppc sparc sparc64 zaurus
MLINKS=apm.8 zzz.8 apm.8 ZZZ.8
Re: DPI for pf(4)
On Tue, Apr 30, 2013 at 07:14:50PM -0400, Ted Unangst wrote: On Wed, May 01, 2013 at 00:16, Franco Fichtner wrote: Yes, I am proposing a lightweight approach: hard-wired regex-like code, no allocations, no reassembly or state machines. I've seen far worse things being put into Kernels and I assure you that I do refrain from putting in anything that could cause segmentation faults, sleeps, or other non-suitable behaviour. And talking about complexity: 1000 LOC for 25 protocols. I'm afraid it can't be simplified any more than this. Well, it's really hard to comment on code we can't see. My thoughts on the matter have always been that it would be cool to integrate bpf into pf (though other developers surely have other opinions). Then you get filtering for as many protocols as you care to write bpf matchers for. My first thought was why not to have something like squid does (ICAP) you can forward some inspection to other app and it would return you some agreed data (tag) and then you could work with then in pf rules... ???
[UPDATE] www/papers/index.html - Eric's OpenSMTPd presentation
Index: index.html === RCS file: /cvs/www/papers/index.html,v retrieving revision 1.166 diff -u -p -r1.166 index.html --- index.html 23 Mar 2013 17:56:07 - 1.166 +++ index.html 2 Apr 2013 13:01:44 - @@ -18,6 +18,13 @@ h3Presentations: AsiaBSDCon 2013/h3 blockquote font color=#009000strong +a href=https://poolp.org/~eric/asiabsdcon2013-smtpd/;OpenSMTPD: We deliver!/a, +Eric Faurot +/strong/fontbr +/blockquote + +blockquote +font color=#009000strong a href=asiabsdcon2013/phessler-bgp-spamd-presentation.pdfUsing BGP for Realtime import and export of OpenBSD SPAMD entries/a, Peter Hessler /strong/fontbr
Re: Fuse (and sshfs) support for OpenBSD
On Tue, Mar 05, 2013 at 02:11:41PM +0100, Gilles Chehade wrote: On Tue, Mar 05, 2013 at 01:49:20PM +0100, Antoine Jacoutot wrote: On Tue, Mar 05, 2013 at 01:43:24PM +0100, Sylvestre Gallon wrote: Hi tech@ I send you this mail because a few months ago I tried to dabble with fuse filesystem and OpenBSD. After some time working on this subject I have succeeded to create something that works. It is not even near to be perfect but with some changes and adaptions I think it could do the job. Before anyone flame you for whatever reason, let me say that I am *very* happy that some work in done in this area. I'll try and play with this and see what comes out of it; may take a little bit of time though. Yup, same here Yes, it would be nice to have libguestfs which uses FUSE working on OpenBSD so one could modify qemu/kvm OpenBSD images directly ;) jirib
Re: raid10 for softraid(4)
On Wed, Feb 20, 2013 at 04:48:57PM +1000, Dmitry Bogdan wrote: Hi, I am interested in implementing layered RAID10 for softraid(4) as a part of my course project in the university. I have a vast expirience in using software raids in openbsd and other operating systems and was surpised that softraid(4) does not support layered RAID10. I know that it is possible to implement raid10 manually (using softraid0 over softraid1), effectively using a lot of drives for speed access without using CPU intensively (compared to raidp and raid6). But if you also want to encrypt it via softraid, it will look like a nightmare to support softraid over softraid over softraid. Raid10 is not an uncommon solution and is often implemented as an independent discipline. Is there any interest in the raid10 independent discipline in openbsd cummunity? http://marc.info/?l=openbsd-miscm=136034083308418w=2 jirib
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: group.5
On Sun, Dec 09, 2012 at 03:07:18PM +1030, David Walker wrote: Hey. I noticed adding a user to wheel doesn't provide su capability automatically. This is described in su(1). I though it might be useful to mention it in group(5) also. --- group.5 Sun Dec 9 14:14:58 2012 +++ group_change.5Sun Dec 9 15:07:29 2012 @@ -81,7 +81,13 @@ .Xr passwd 5 entry and does not need to be added to that group in the .Nm -file. +file. Members of the +.Dq wheel +group, who wish to run commands as +.Dq root , +using +.Xr su 1 , +must be explicitly listed. .\ .Pp .\ When the system reads the file .\ .Pa /etc/group It would probably make more sense to change su(1) that 'wheel' is secondary group in this context. jirib
Re: hostname.if(5) clarification
On Tue, Nov 27, 2012 at 10:25:39AM +0200, Gregory Edigarov wrote: On 11/27/2012 09:03 AM, Claudio Jeker wrote: On Mon, Nov 26, 2012 at 05:36:20PM -0700, Theo de Raadt wrote: If there are desires to improve this (I hear Naddy grumbling!) then the stomach to break backwards compat must be present, or suggestions on how to do it without breaking backwards compat must be suggested. My suggestion is two-fold: * Introduce a new format. This new format will ignore # comments, call ! commands, but otherwise pass on everything unchanged to ifconfig. I'm neutral on the matter of retaining dhcp and rtsol as shortcuts for !dhclient \$if and !rtsol \$if. * To maintain backward compatibility, retain the old parsing for hostname.* files. Interface configuration files in the new format will have a different name; if.* or whatever. Does that sound workable? Not really. The netbsd experiment with ifconfig file format does not appear to have been a success. reason why? ifconfig has a really crummy argument parser, with all sorts of side effects. hostname.* files were supposed to isolate people from some of those nasty effects. stated simply, it would not have helped Paul. He would have made the same mistake. Plus some interface changes need multiple ifconfig commands and a specific order to work. I think there is no way to express complex interface configurations without having an order in which the operations are done. Sure it is possible to throw the ordering all into netstart but I think that is not helpful. hostname.if is exactly what I dislike in all OpenBSD. I think the whole concept of it is leading to errors and misunderstanding. The very design is flawed. What I do right after the first boot is: mv /etc/netstart /etc/netstart.dist rm -f /etc/hostname.* and then vi /etc/netstart, inserting the plain ifconfigs, routes, call of clients etc. that way i have full control over network configuration. IIRC Edd Barrett has an idea to create ifconfid - a daemon which would setup networking on OpenBSD. http://marc.info/?l=openbsd-techm=130450257324306w=2#1 jirib
Re: Major dhclient(8) changes - no more dhclient-script
On Wed, Nov 14, 2012 at 08:35:52AM -0500, Kenneth R Westerback wrote: On Tue, Nov 13, 2012 at 03:14:40PM -0500, sven falempin wrote: 2012/11/9 Kenneth R Westerback kwesterb...@rogers.com Those of you following -current or running very recent snaps may have noticed a lot of changes to dhclient in the last couple of weeks. Aside from some major clean up, these changes revolve around the elimination of the dhclient-script as both detrimental to sanity and our ability to move forward to better network configuration automation. So far a couple of uses for dhclient-script have been reported and workarounds have to be developed for these scenarios. But now that most of the changes are committed we are very interested in making sure that scenarios that lead people to modify dhclient-script are identified sooner rather than later. So please test the new dhclient(8) in as many situations as possible and report both 'noraml' bugs/regressions and problems you have not been able to solve without dhclient-script. Thanks. How to prevent deleting of /etc/resolv.conf by dhclient? I have this: # egrep -v ^#|^[ \t]*$ /etc/dhclient.conf ignore domain-name-servers, domain-name; The goal is to have always my own /etc/resolv.conf. I'm using pdnsd, the best would be to catch offerent dns server and if OK I would like to do someting with that. (I was using that on Ubuntu, caching if offered dns servers are ones from my job, if so and then into pdnsd setup; because internal company's dns server sucked a lot and I was using other public dns for normal recursive queries but going via internal company's ones only for specific domains.) Anway, I don't like to be without /etc/resolv.conf and also have there so stupid dns offered by dhcp. Thanks for tips. jirib
Re: Major dhclient(8) changes - no more dhclient-script
On Fri, Nov 09, 2012 at 09:44:01AM -0500, Kenneth R Westerback wrote: Those of you following -current or running very recent snaps may have noticed a lot of changes to dhclient in the last couple of weeks. Aside from some major clean up, these changes revolve around the elimination of the dhclient-script as both detrimental to sanity and our ability to move forward to better network configuration automation. So far a couple of uses for dhclient-script have been reported and workarounds have to be developed for these scenarios. But now that most of the changes are committed we are very interested in making sure that scenarios that lead people to modify dhclient-script are identified sooner rather than later. So please test the new dhclient(8) in as many situations as possible and report both 'noraml' bugs/regressions and problems you have not been able to solve without dhclient-script. Thanks. Ken Well, resolv.conf(5) has many neat options which one could like to have added into resolv.conf even when using dhcp to get dns servers. One of them could be: family, some options like tcp... I don't want to be nitpick but with personalized dhclient-script one could code whatever to have valid resolv.conf(5) settings in his /etc/resolv.conf. jirib
Re: upstream vendors and why they can be really harmful
On Tue, Nov 06, 2012 at 01:15:04PM +, Kevin Chadwick wrote: It could well end up the other way around, with systemd dying. It does far too much and most of which is pointless in order to gain traction but also limiting it's scope and so success unless it is forked or radically changed of course. The amount of code running as root is rediculous too. Even Redhat devs have said it offers little and it certainly causes major problems even for Linux. Some RH guys don't like only from sysadmin or job point of view, in F19 there should be no /var/log/messages or they are worried about how to support environments and apps which uses this files to parse it. This also contains big finantial level but as Fedora is playground nobody cares there much about this topic. Most Linux distros will move to systemd anyway, even Debian I bet. They already moved to stupid Upstart (like RHEL 6 IIRC). jirib
Re: System is halted while installing on IBM x 3550 M3 server
On Mon, Aug 20, 2012 at 05:27:21PM +0530, mu...@nitrkl.ac.in wrote: I cant send dmesg because i got this panic trap after booting from CDROAM while installing Openbsd on IBM x 3550 M3 server. i am using i386 Arch CDROM. Use serial port as console. You need to create your own iso so it contains /etc/boot.conf defining 'set tty com0' See: http://www.openbsd.org/cgi-bin/cvsweb/src/distrib/amd64/iso/Makefile?rev=1.6 http://www.openbsd.org/faq/faq7.html#SerCon j.
Re: Virtio drivers for OpenBSD V3
On Thu, Jul 26, 2012 at 07:41:56AM +0200, Tobias Wigand wrote: Hi, In case someone is interested, I have tried to run a comparison between the new Virtio network driver and e1000 emulation. This is more of a real life home usage example, I have used my personal firewall setup for the tests. Your results may vary. I have issued pfctl -Fa for the tests. The tests were done against an old Dell D600 running Ubuntu. I have not run any tests on the storage driver, but using it the KVM guest feels much faster, especially booting or shutting down is really fast for me. Little OT - most KVM has libvirt as backend, if anybody would like to help with an issue of libvirt on OpenBSD, check here (and thanks!): https://bugzilla.redhat.com/show_bug.cgi?id=781374 jirib
Re: UPDATE: pcidevs - vmxnet3
On Fri, Jul 20, 2012 at 09:24:51AM +0200, Johan Ryberg wrote: Thanks =) Do you know if OpenBSD current support vmxnet3? vlan has been problematic last time I tested in 4.9 And do you have updated if_vic.c ? I'm not programmer :( jirib
UPDATE: pcidevs - vmxnet3
Hello, to make vmxnet3 recognized. jirib $ cvs diff -uNp pcidevs Index: pcidevs === RCS file: /cvs/OpenBSD/src/sys/dev/pci/pcidevs,v retrieving revision 1.1654 diff -u -p -r1.1654 pcidevs --- pcidevs 18 Jul 2012 09:25:27 - 1.1654 +++ pcidevs 19 Jul 2012 21:27:13 - @@ -5940,6 +5940,7 @@ product VLSI 82C925 0x0280 82C925 product VMWARE VIRTUAL20x0405 Virtual SVGA II product VMWARE VIRTUAL 0x0710 Virtual SVGA product VMWARE NET 0x0720 Virtual NIC +product VMWARE NET30x07b0 Virtual NIC3 product VMWARE MACHINE_2 0x0740 Virtual Machine Communication Interface product VMWARE EHCI0x0770 Virtual EHCI product VMWARE PCI 0x0790 Virtual PCI-PCI
Re: Any idea of donate a Raspberry Pi to a developer?
On Wed, Jul 18, 2012 at 01:28:13PM +0200, Otto Moerbeek wrote: On Tue, Jul 17, 2012 at 07:55:28PM +0200, Johan Ryberg wrote: You simply just throw another persons political opinion on me. I have read that thread as well but that's not the point. Do you honestly believe that one answer speaks for all other very skilled developers? It's a fact that the Pi is a case of severely underdocumented blobby hardware. It's chances in OpenBSD land are close to zero. -Otto According to hubertf's blog, this boots on NetBSD http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20120714_0236.html jirib
Re: Virtio drivers for OpenBSD
On Thu, Jul 12, 2012 at 11:02:54AM +0200, Stefan Fritsch wrote: On Wed, 11 Jul 2012, Matthew Dempsky wrote: There are quite a few pretendy-SCSI drivers in the tree, but most of them deal with fairly complicated hardware so they're not good reference points. sparc64's vdsk(4) driver is probably the best reference point, since it's also for a virtual disk driver (see sys/arch/sparc64/dev/vdsk.c). If you would like to dig into vmware pvscsi support, I'm more than happy to do testing :) http://lxr.linux.no/#linux+v3.4.4/drivers/scsi/vmw_pvscsi.c jirib
Re: Virtio drivers for OpenBSD
On Wed, Jul 11, 2012 at 01:01:03PM -0700, Matthew Dempsky wrote: I'm not terribly familiar with mpi(4), but I see it has code to call scsi_req_probe() if it receives a MPI_EVT_SASCH_REASON_ADDED or MPI_EVT_SASCH_REASON_NO_PERSIST_ADDED event from the adapter controller. However, it appears to only watch for events from Serial Attached SCSI and Fibre Channel controllers, whereas 53c1030 is a Parallel SCSI controller. Are you able to configure VMWare to emulate a different mpi(4) device? E.g., one that uses SAS or FC instead? Do you use the 53c1030 with Linux too? Yes, Linux uses 53c1030 for LSI Logic Parallel as well. LSI SAS is available on ESXi 5.x but it is not, as stu@ pointed out, recognized. VMware Virtual Machine Communication Interface rev 0x10 at pci0 dev 7 function 7 not configured Full dmesg: booting cd0a:/5.2/amd64/bsd.rd: |/-\|/2994884-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|+917612/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- \|/-\|/+2864584-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| /-\|/-\|/-\|/-\|/-\|/-\|/-\|+0+531328/ [89-+320208\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ -\|/-\|/-\|/-\+207144|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/]=0xb7ab18 entry point at 0x1001e0 [7205c766, 3404, 24448b12, b5f8a304] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2012 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.2-beta (RAMDISK_CD) #90: Thu Jun 28 01:19:28 MDT 2012 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 133103616 (126MB) avail mem = 109703168
Re: Virtio drivers for OpenBSD
On Wed, Jul 11, 2012 at 02:13:03PM +0200, Otto Moerbeek wrote: On Wed, Jul 11, 2012 at 02:07:00PM +0200, Stefan Fritsch wrote: Hi, I have been working on porting NetBSD's virtio drivers to OpenBSD. I am not finished yet, but in order to prevent duplicate work, I thought I'd publish the current state (attached as diff to OpenBSD 5.1). It adds a virtio block device driver (viod) and a virtio network interface (if_vioif). It is stable enough to run make -j 2 in /usr/src on a viod disk. Comments are welcome. BTW: Which device numbers should I choose for viod? Use the first unused number or just add virtio at the end? Cheers, Stefan [demime 1.01d removed an attachment of type TEXT/x-diff which had a name of openbsd-virtio-v1.diff] Only ports@ allows attachment, IIRC. Paste a link or better include inline. Can you give us some examples of the use of this driver? OpenBSD running under KVM (Linux, Solaris, Bitrig... :DDD )? jirib
Re: Virtio drivers for OpenBSD
On Wed, Jul 11, 2012 at 01:24:08PM +0100, Stuart Henderson wrote: if you're hacking on things for possibly inclusion, it's a *much* better idea to do it against -current. Or even better, it would be much important to make OpenBSD to see added disks without reboot (it means rescanning the bus). jirib
Re: Virtio drivers for OpenBSD
On Wed, Jul 11, 2012 at 08:37:32AM -0700, Matthew Dempsky wrote: On Wed, Jul 11, 2012 at 6:01 AM, Jiri B ji...@devio.us wrote: Or even better, it would be much important to make OpenBSD to see added disks without reboot (it means rescanning the bus). I don't understand what you're referring to here. OpenBSD already handles hotplugged disks in quite a few cases; e.g., USB and some other SCSI drivers. (Notably ahci(4) does not yet though.) Like this one... mpi0 at pci0 dev 16 function 0 Symbios Logic 53c1030 rev 0x01: apic 2 int 17 scsibus1 at mpi0: 16 targets, initiator 7 sd0 at scsibus1 targ 0 lun 0: VMware, Virtual disk, 1.0 SCSI2 0/direct fixed sd0: 61440MB, 512 bytes/sector, 125829120 sectors For example on Linux you can add new disk and rescan, the disk is visible. I can test on one ESXi 5. jirib
Re: Future of PF
On Sat, May 19, 2012 at 10:51:31PM +0300, wishmaster wrote: Hi. I use PF in both OS'es: Free and OpenBSD. This is great firewall. But today statefull firewalling and inspecting packet headers only, traffic classification and prioritization by port number only - it is not enough for complex firewalling/shaping/prioritization/etc. Outside window - XXIst century and today it is necessary to have more advanced tool. I am about DIFFUSE. http://www.caia.swin.edu.au/urp/diffuse/intro.html In future (maybe in 10.X) it will be in the base FreeBSD system as part of IPFW. It is available for Linux and OpenWRT as well. My suggestion is to integrate DIFFUSE into PF as well. We need keep pace with time and only this way will let PF to be one of the best firewall solution. You can suggest whatevery you want, words are for free : jirib
