Re: USB serial local getty terminal re-prompts for login on any input

2023-10-27 Thread Morgan Aldridge 
On Thu, Oct 26, 2023 at 9:03 PM Theo de Raadt  wrote:

>
> Crystal Kolipe  wrote:
>
> > On Thu, Oct 26, 2023 at 12:20:08PM -0400, Morgan Aldridge wrote:
> > > Yes, your assumption was correct, every keypress acts as if I had
> pressed
> > > enter. Thanks for confirming!
> >
> > Getty re-displays the login prompt when it sees either 0x00 or 0x80 on
> the
> > serial line.  In fact, you can do it from the normal framebuffer console
> too,
> > just hit control-@ at the login prompt and it should repeat.
> >
> > (This is a historic behaviour which was once used for semi-automatic
> baud rate
> >  selection where you hit 'BREAK' a few times to get the remote end to
> cycle
> >  through all the speeds it supported until you, (hopefully), got a login
> >  prompt).
> >
> > So in your case, it seems that either the terminal is putting something
> on the
> > serial data lines that the USB serial adaptor is interpreting as nulls,
> or
> > possibly it's doing something with the handshaking lines that makes the
> > USB serial adaptor generate the equivalent internally.
> >
> > Any extra nulls added as padding bytes probably wouldn't show up in the
> > loopback test either, because the terminal would just happily ignore
> them.
>
> ktrace -di of the process will show what is going on
>

Thank you both!

Confirmed with `ktrace -di -g $(pgrep -f "getty std.9600 ttyU")` and
pressing a single character ('l'; a lower-case el... in hindsight, I should
have used a more recognizable character) on the connected terminal:

 14294 gettyCALL  read(0,0x78e711dd4246,0x1)
 14294 gettyGIO   fd 0 read 1 bytes
   "\0"
 14294 gettyRET   read 1

So, yeah, there's the null being received. The 'l' never is, but that jives
with what you've described regarding getty(8).

I disabled getty(8) on ttyU1, ran `cu -dr -l ttyU1 -s 9600`, then `ktrace
-di -g $(pgrep -f "cu -dr -l ttyU")`, and again pressed a single character
('l' again) on the connected terminal:

 62099 cu   CALL  read(3,0x2f26a7f400,0x2)
 62099 cu   GIO   fd 3 read 2 bytes
   "\0l"
 62099 cu   RET   read 2

Confirmed: there's the null being received before the 'l'. As you mentioned
was likely, cu(1) just ignores the null byte.

Performing the same cu(1) & ktrace(1) test with the TX/RX pins shorted and
pressing a single character ('l' again) in cu(1):

 72982 cu   CALL  write(3,0xbf9b0baf900,0x1)
 72982 cu   GIO   fd 3 wrote 1 bytes
   "l"
 72982 cu   RET   write 1
 72982 cu   CALL  kevent(4,0,0,0xbf9b0b8d000,64,0)
 72982 cu   STRU  struct kevent { ident=3, filter=EVFILT_READ,
flags=0x11, fflags=0<>, data=2, udata=0xbf9b0bb3c08 }
 72982 cu   RET   kevent 1
 72982 cu   CALL  ioctl(3,FIONREAD,0x74351e9ae74c)
 72982 cu   RET   ioctl 0
 72982 cu   CALL  read(3,0xbf9b0babd00,0x2)
 72982 cu   GIO   fd 3 read 2 bytes
   "\0l"
 72982 cu   RET   read 2

So, there it is, a single 'l' is written, but a null is read prior to the
'l'. So, it's the Keyspan/Tripp-Lite USA-19HS which is adding the null
byte. Again, I suspect the lack of flow-control implementation in ukspan(4)
is the culprit.

This weekend I'll do some more analysis with ktrace(1), especially loopback
tests with flow control lines shorted. I'll use my findings to work on
updating ukspan(4)'s ukspan_param() to handle flow control related c_cflag
masks such as CLOCAL, CCTS_OFLOW, CRTS_IFLOW, and MDMBUF, as described in
termios(4).

Morgan

Re: USB serial local getty terminal re-prompts for login on any input

2023-10-26 Thread Morgan Aldridge 
On Thu, Oct 26, 2023 at 6:26 AM Crystal Kolipe 
wrote:

> On Wed, Oct 25, 2023 at 01:35:39PM -0400, Morgan Aldridge wrote:
> > On the terminal, keeping the same 9600 8N1 settings, but enabling local
> > echo, and shorting the TX/RX pins gets me duplicated input with no odd
> > characters or breaks (AFAICT).
> >
> > On the OpenBSD side (with getty disabled on the tty, of course), I ran
> `cu
> > dr -l ttyU1 -s 9600` and jumped the TX/RX pins, and confirmed that the
> > characters entered were received back without any breaks or odd
> characters
> > (though there's no local echo.) I confirmed that cu(1) is just not
> echoing
> > locally by un-jumping the TX/RX pins and seeing that I did _not_ receive
> > the characters entered.
>
> OK, so the hardware is essentially working, that's good.
>
> Could you confirm exactly what you meant when you said:
>
> On Mon, Oct 23, 2023 at 11:37:10PM -0400, Morgan Aldridge wrote:
> > Unfortunately, regardless of what input is provided on the
> > terminal, getty(8) just sends a new login prompt.
>
> Do you mean that:
>
> 1. Any single keypress triggers a new login prompt, (as if you were
> pressing
>enter each time).
>
> or
>
> 2. You can successfully enter a username, which is echoed back but then
>pressing enter the system just presents you with another login prompt
>instead of accepting the username and asking for a password.
>
> I assumed it was '1', but just want to check before going any further.
>

Yes, your assumption was correct, every keypress acts as if I had pressed
enter. Thanks for confirming!

Morgan

Re: USB serial local getty terminal re-prompts for login on any input

2023-10-25 Thread Morgan Aldridge 
On Wed, Oct 25, 2023 at 1:35 PM Morgan Aldridge 
wrote:

> On Tue, Oct 24, 2023 at 5:52 AM Crystal Kolipe 
> wrote:
>
>> On Mon, Oct 23, 2023 at 11:37:10PM -0400, Morgan Aldridge wrote:
>> > I have experimented with the following with no change in the underlying
>> > issue of the terminal showing the login prompt, but each character input
>> > causing the login prompt to be resent:
>>
>> If you short the tx/rx lines at the DE-9 end and then access the serial
>> device using /usr/bin/cu on the OpenBSD machine, does your input
>> reliably each back to you?  Or are some characters lost or garbled?
>>
>> (Obviously remove or disable the ttys line for this test.)
>>
>
> Excellent suggestions!
>
> I have since found the pinouts for the serial cable and successfully
> confirmed the wiring, no shorts to ground or other pins, and no odd
> resistance on any of the connections. That's a good start.
>
> On the terminal, keeping the same 9600 8N1 settings, but enabling local
> echo, and shorting the TX/RX pins gets me duplicated input with no odd
> characters or breaks (AFAICT).
>
> On the OpenBSD side (with getty disabled on the tty, of course), I ran `cu
> dr -l ttyU1 -s 9600` and jumped the TX/RX pins, and confirmed that the
> characters entered were received back without any breaks or odd characters
> (though there's no local echo.) I confirmed that cu(1) is just not echoing
> locally by un-jumping the TX/RX pins and seeing that I did _not_ receive
> the characters entered.
>
>
>> You might need to short rts/cts and dtr/dsr as well depending on your
>> hardware handshaking setup.
>>
>
> I _think_ I have not enabled hardware handshaking, but will test this
> next. Also, having just typed this out, I realize I forgot to test using
> cuaU1 with cu(1), in addition to ttyU1.
>

I haven't gotten to more physical testing yet, but have taken a quick peek
at ukspan.c (see [0]) and noticed that ukspan_param() has a nice,
reassuring "/* XXX flow control? */" comment. That and the fact that it's
not handling any of the flow control related c_cflag masks such as CLOCAL,
CCTS_OFLOW, CRTS_IFLOW, or MDMBUF (see termios(4), specifically [1])
certainly implies that my fiddling with any of those options in /etc/ttys
has not been having any effect. If that's the case, I have some development
work to do... after my aforementioned remaining troubleshooting.

I've not worked on drivers before (aside from adding some device IDs), but
this looks like about the most straight-forward introduction that could
possibly be laid out in front of me.

[0] <
http://cvsweb.openbsd.org/src/sys/dev/usb/ukspan.c?rev=1.4&content-type=text/x-cvsweb-markup
>
[1] <http://man.openbsd.org/termios.4#Control_Modes>

Morgan

Re: USB serial local getty terminal re-prompts for login on any input

2023-10-25 Thread Morgan Aldridge 
On Tue, Oct 24, 2023 at 5:52 AM Crystal Kolipe 
wrote:

> On Mon, Oct 23, 2023 at 11:37:10PM -0400, Morgan Aldridge wrote:
> > I have experimented with the following with no change in the underlying
> > issue of the terminal showing the login prompt, but each character input
> > causing the login prompt to be resent:
>
> If you short the tx/rx lines at the DE-9 end and then access the serial
> device using /usr/bin/cu on the OpenBSD machine, does your input
> reliably each back to you?  Or are some characters lost or garbled?
>
> (Obviously remove or disable the ttys line for this test.)
>

Excellent suggestions!

I have since found the pinouts for the serial cable and successfully
confirmed the wiring, no shorts to ground or other pins, and no odd
resistance on any of the connections. That's a good start.

On the terminal, keeping the same 9600 8N1 settings, but enabling local
echo, and shorting the TX/RX pins gets me duplicated input with no odd
characters or breaks (AFAICT).

On the OpenBSD side (with getty disabled on the tty, of course), I ran `cu
dr -l ttyU1 -s 9600` and jumped the TX/RX pins, and confirmed that the
characters entered were received back without any breaks or odd characters
(though there's no local echo.) I confirmed that cu(1) is just not echoing
locally by un-jumping the TX/RX pins and seeing that I did _not_ receive
the characters entered.


> You might need to short rts/cts and dtr/dsr as well depending on your
> hardware handshaking setup.
>

I _think_ I have not enabled hardware handshaking, but will test this next.
Also, having just typed this out, I realize I forgot to test using cuaU1
with cu(1), in addition to ttyU1.

Morgan

USB serial local getty terminal re-prompts for login on any input

2023-10-23 Thread Morgan Aldridge 
(Not subscribed to misc@, so please CC me in all replies.)

I've got an odd situation that I'm having trouble getting to the bottom of,
but I'll first admit that I haven't been able to yet rule out a hardware
issue and I also may currently be too close to the problem (despite
sleeping on it several times):

I have an external VT100 terminal connected to my 2015 13in MacBook Air
running OpenBSD amd64/7.4-release/stable via a Keyspan/Tripp-Lite USA-19HS
USB to DB-9 serial adapter. The USA-19HS uses ukspan(4) which was added in
6.6. I've added a ttys(5) line, HUPed INIT, have run ttyflags(8) (more
specifics below), have the terminal configured for 9600 8N1 with no flow
control, and the terminal does display the login prompt generated by
getty(8). Unfortunately, regardless of what input is provided on the
terminal, getty(8) just sends a new login prompt.

I only have the one USA-19HS, one specific original serial cable, and the
terminal, all the exact set that were used approximately 10 years ago.
Though, at that time I was connecting it to an Intel MacBook Pro running
some version of Mac OS X with the Keyspan drivers installed and similarly
using getty. I have performed hardware repairs on the terminal, so -- again
-- I can't yet rule out hardware issues and certainly not driver issues.

dmesg (trimmed; full at the end, including `usbdevs -v` output):

```
ukspan0 at uhub3 port 3 "Keyspan, a division of InnoSys Inc. Keyspan
USA-19H" rev 1.10/1.00 addr 20
ucom1 at ukspan0: usb0.1.00334.
```

/etc/ttys

```
console "/usr/libexec/getty std.9600"   vt220   off secure
ttyU1   "/usr/libexec/getty std.9600"   vt100   on local
```

Per ttys(5), whenever I modify /etc/ttys, I do the following:

```
doas kill -HUP 1
doas ttyflags -va
doas ttyflags -p ttyU1
pgrep -fl ttyU1
top -g ttyU1
```

I've found it more reliable -- when making changes -- to specifically set
my ttys(5) line to 'off', perform the aforementioned steps, then change the
line to 'on' and repeat.

I have experimented with the following with no change in the underlying
issue of the terminal showing the login prompt, but each character input
causing the login prompt to be resent:

- ttys(5) 'secure' option (shouldn't be necessary, since I don't intend to
authenticate as root)
- ttys(5) 'local' option
- ttys(5) 'softcar' option (shouldn't be necessary, since I am getting a
connection; see [0])
- either "no flow control" or "software flow control" enabled on the
terminal
- ttys(5) 'rtscts' option with "hardware flow control" enabled on the
terminal
- ttys(5) 'mdmbug' option with "hardware flow control" enabled on the
terminal
- ttys(5) 'rtscts' and 'mdmbug' options with "hardware flow control"
enabled on the terminal

I also tried specifying 'cuaU1' device instead of 'ttyU1' for all of the
above (see [1]) with no change, other than `ttysflags -a` saying the device
is busy and not setting any flags.

I have tried different speeds, writing custom gettytab(5) lines to change
various XON/XOFF settings and "software flow control" enabled on the
terminal.

My next steps, when I have time and in no particular order, are to:

- Retry various experiments with getty(8) off and using cu(1) to connect
directly to the terminal, sending characters back and forth from each end
- Try on a couple other pieces of amd64 & i386 hardware running OpenBSD
which have built-in serial (they need upgrades to 7.4 and I don't recall
the state of serial hardware support)
- Order a USB to DB-9 serial adapter with genuine FTDI chips (that may rule
out driver issues, but would also likely let me test under macOS on my M1
Mac mini)
- Test and map the pinouts on the original serial cable

I'm really only looking for confirmation that the source[2] I used to
refresh my memory on software (XON/XOFF) vs hardware (RTS/CTS and/or
DTR/DCD) flow control is reasonably accurate and if my description of this
issue jumps out to you as any likely cause.

Thanks in advance for any thoughts or suggestions,

Morgan

[0] 
[1] 
[2] 

OpenBSD 7.4 (GENERIC.MP) #1397: Tue Oct 10 09:02:37 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8469352448 (8077MB)
avail mem = 8192921600 (7813MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afac000 (33 entries)
bios0: vendor Apple Inc. version "195.0.0.0.0" date 06/11/2020
bios0: Apple Inc. MacBookAir7,2
efi0 at bios0: UEFI 1.1
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT
SSDT SSDT DMAR MCFG
acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S4)
ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acp

Re: Firefox toLocaleString displays wrong time on OpenBSD

2023-08-03 Thread Morgan Aldridge 
On  2021-04-29, Marfaba Stewart wrote:

> I'm confused about Firefox's handling of Date objects on OpenBSD.
>
> Why: Some Firefox browser extensions that display dates using
> Date.toLocaleString or Date.toLocaleDateString can cause an incorrect
> date to be displayed. For example, using a credit card expiration
> displayed as "01/23" when it really expires in February 2023 will make
> payments fail.
>
> Synopsis: Calling toLocaleString without parameters on a date object
> seems to yield the wrong time.
>
> Description: Calling toLocaleString without parameters yields a
> time that is one hour off for CST and two hours off for CDT.  This
> seems to happen only on Firefox with OpenBSD -- not on Chromium on
> the same machine, nor on Firefox on other operating systems that
> I've tried.
>
> This problem will show up if you go to Web Developer -> Web Developer
> Tools and try any dates in the console.
>
> However, if you are in a Preferences tab and try it in the web
> developer console, the error will NOT show up.
>
> The error will also NOT show up if you use Date.toLocaleString
> within a regular web page.
>
> It only appears for me from the browser extension that uses
> Date.toLocaleString, and in the developer console from a tab that
> is not "Preferences."
>
> I think this is a Firefox bug and have reported it to Mozilla.
> I've reproduced the error on many OpenBSD machines for the last
> several months all running -current, with various version of Firefox,
> including 88.0.
>
> (My first attempt to get the source from ports failed because of
> an anemic machine, but I will try again with more memory.)
>
> Sadly, I've been banging my head against this problem for a long
> time. I initially and stupidly submitted to the wrong forum, and
> compounded the problem with an ill-formatted date, although I had
> tried valid dates as well. My example was unfortunate because, as
> far as I can tell, any date will generate this problem.
>
> My BIOS time is set to UTC and /etc/localtime points to US/Central.
> I've also tried changing the BIOS time to my local time and setting
> kern.utc_offset, but nothing changed.
>
> I also tried the Firefox option to use the operating system's setting
> to format dates just to see if that might affect anything, not
> expecting it to change anything.  Indeed, nothing changed.
>
> As far as I can tell from reading developer.mozilla.org about
> Date and Date.prototype.toLocalString and international formats, etc.,
> calling toLocaleString without parameters might use an
> unpredictable format, but the time displayed should be local time.
>
> Some forum posts such as
>
> https://stackoverflow.com/questions/33083936/
> convert-date-to-local-time-zone-with-tolocalestring-method-firefox
>
> say this is a bug in Firefox.
>
> How-To-Repeat:
> From Web Developer -> Web Developer Tools in Firefox:
> (with input and output marked, and comments starting with #)
>
> # I've created the dates with new Date but
> # new Date(Date.UTC(.)) doesn't change the results
> # of the call to toLocaleString
>
> # create date in Central Standard Time. so far so good
> INPUT: event1 = new Date(2021, 0, 1, 12, 0, 0)
> OUTPUT Date Fri Jan 01 2021 12:00:00 GMT-0600 (CST)
>
> # output below of toLocaleString() is one hour before local
> # time. Happens to match Canada/Mountain
>
> INPUT: event1.toLocaleString()
> OUTPUT: "1/1/2021, 11:00:00 AM"
>
> INPUT: event1.toLocaleString('en-US', {timeZone: "Canada/Mountain"})
> OUTPUT: "1/1/2021, 11:00:00 AM"
>
> INPUT: event1.toLocaleString('en-US', {timeZone: "US/Central"})
> OUTPUT: "1/1/2021, 12:00:00 PM"
>
> # create date in Central Daylight Time. so far so good
> INPUT: event2 = new Date(2021, 3, 29, 12, 0, 0);
> OUTPUT: Date Thu Apr 29 2021 12:00:00 GMT-0500 (CDT)
>
> # output below of toLocaleString()is two hours before local
> # time. Happens to match Canada/Pacific
>
> INPUT: event2.toLocaleString()
> OUTPUT: "4/29/2021, 10:00:00 AM"
>
> INPUT: event2.toLocaleString('en-US', {timeZone: "Canada/Pacific"})
> OUTPUT: "4/29/2021, 10:00:00 AM"
>
> INPUT: event2.toLocaleString('en-US', {timeZone: "US/Central"})
> OUTPUT: "4/29/2021, 12:00:00 PM"
>
> Fix: A workaround in the console: specify parameters to toLocaleString.
> To workaround the display problem in the browser extension, set
> privacy.resistfingerprinting to true. I think everything looks like
> UTC, so any conversion problems seem to go away.


I was troubleshooting a related issue in firefox 115.0.1 under OpenBSD
amd64/7.3-stable and confirmed the same issue you did with
Date.toLocaleString() being off by an hour. Fortunately, I found a
solution: ensuring TZ is set in the environment before launching firefox.

The original issue I found was that, despite local time being correct and
all other applications functioning correctly for years, firefox was
inconsistent about times, especially the local timezone, in JavaScript.

In terminal applications, I confirmed:

$ ls -al /etc/localtime
lrwxr-xr

Re: xenodm + Xvfb + x11vnc = virtual display for vmm(4) OpenBSD guests

2023-07-19 Thread Morgan Aldridge 
On Tue, Jul 18, 2023 at 5:42 PM Morgan Aldridge
 wrote:
>
> On On 2023-07-18, Stuart Henderson  wrote:
> > On 2023-07-18, Morgan Aldridge  wrote:
> > > I'm maintaining an OpenBSD X11 window manager (WM) port, but try to
> > > keep my primary workstation on -stable, so do most of my development
> > > there and test in Xephyr. I test & submit patches from an OpenBSD
> > > -current VM running under vmm(4), but since vmm(4) doesn't emulate
> > > video hardware, I haven't been run-testing there.
> > >
> > > I'm already comfortable with x11vnc under OpenBSD, plus Xephyr, but
> > > they both use an existing X display. After studying xenodm(1),
> > > Xvfb(1), x11vnc(1), and a bunch of other X(1)-related manual pages,
> > > plus tons of experimenting, the solution was actually quite simple.
> > >
> > > TL; DR
> > >
> > > I could find much on the Internet, list archives, etc., regarding this
> > > specific situation, so here's my solution for a [slow] X11 virtual
> > > display on a vmm(4) OpenBSD guest, accessible via VNC over an SSH
> > > tunnel:
> > >
> > >   doas rcctl enable xenodm
> > >   doas rcctl set xenodm flags \
> > > "-server ':0 local /usr/X11R6/bin/Xvfb :0 -screen 1024x768x24 -shmem'"
> > >   doas rcctl start xenodm
> > >   doas pkg_add x11vnc
> > >   doas rcctl enable x11vnc
> > >   doas rcctl start x11vnc
> > >
> > > Hope someone else finds this useful down the road,
> >
> > I recommend putting x11vnc in the bin and using tigervnc if it works for
> > your configuration...
>
> Thanks! TigerVNC's x0vncserver(1) seems to work similarly to x11vnc(1)'s
> default rc.d flags when executed as follows:
>
>   x0vncserver -SecurityTypes None -localhost
>
> This doesn't require a password (WARNING!), but does require an SSH
> tunnel to access. Is certainly snappier too!
>
> Easy enough to copy /etc/rc.d/x11vnc (before uninstalling) and update
> the 'daemon' & 'daemon_flags' values as follows:
>
>   daemon="/usr/local/bin/x0vncserver"
>   daemon_flags="-SecurityTypes None -localhost"
>
> I'm pretty sure 'rc_bg=YES' & 'rc_reload=NO' would need to be retained.

Oops, x0vncserver doesn't automatically find the appropriate
.Xauthority like x11vnc's `-auth guess` does, so while it works when
run as your user and already logged in via xenodm, it doesn't actually
work correctly from rc.d as I suggested above.

I'll investigate and do some further testing, but the nice thing about
x11vnc is that it handles the xenodm login window, plus logging in and
out as various users. Naturally, this is convenient for window manager
& desktop environment testing.

Morgan

Re: xenodm + Xvfb + x11vnc = virtual display for vmm(4) OpenBSD guests

2023-07-18 Thread Morgan Aldridge 
On On 2023-07-18, Stuart Henderson  wrote:
> On 2023-07-18, Morgan Aldridge  wrote:
> > I'm maintaining an OpenBSD X11 window manager (WM) port, but try to
> > keep my primary workstation on -stable, so do most of my development
> > there and test in Xephyr. I test & submit patches from an OpenBSD
> > -current VM running under vmm(4), but since vmm(4) doesn't emulate
> > video hardware, I haven't been run-testing there.
> >
> > I'm already comfortable with x11vnc under OpenBSD, plus Xephyr, but
> > they both use an existing X display. After studying xenodm(1),
> > Xvfb(1), x11vnc(1), and a bunch of other X(1)-related manual pages,
> > plus tons of experimenting, the solution was actually quite simple.
> >
> > TL; DR
> >
> > I could find much on the Internet, list archives, etc., regarding this
> > specific situation, so here's my solution for a [slow] X11 virtual
> > display on a vmm(4) OpenBSD guest, accessible via VNC over an SSH
> > tunnel:
> >
> >   doas rcctl enable xenodm
> >   doas rcctl set xenodm flags \
> > "-server ':0 local /usr/X11R6/bin/Xvfb :0 -screen 1024x768x24 -shmem'"
> >   doas rcctl start xenodm
> >   doas pkg_add x11vnc
> >   doas rcctl enable x11vnc
> >   doas rcctl start x11vnc
> >
> > Hope someone else finds this useful down the road,
>
> I recommend putting x11vnc in the bin and using tigervnc if it works for
> your configuration...

Thanks! TigerVNC's x0vncserver(1) seems to work similarly to x11vnc(1)'s
default rc.d flags when executed as follows:

  x0vncserver -SecurityTypes None -localhost

This doesn't require a password (WARNING!), but does require an SSH
tunnel to access. Is certainly snappier too!

Easy enough to copy /etc/rc.d/x11vnc (before uninstalling) and update
the 'daemon' & 'daemon_flags' values as follows:

  daemon="/usr/local/bin/x0vncserver"
  daemon_flags="-SecurityTypes None -localhost"

I'm pretty sure 'rc_bg=YES' & 'rc_reload=NO' would need to be retained.

Morgan

xenodm + Xvfb + x11vnc = virtual display for vmm(4) OpenBSD guests

2023-07-18 Thread Morgan Aldridge 
I'm maintaining an OpenBSD X11 window manager (WM) port, but try to
keep my primary workstation on -stable, so do most of my development
there and test in Xephyr. I test & submit patches from an OpenBSD
-current VM running under vmm(4), but since vmm(4) doesn't emulate
video hardware, I haven't been run-testing there.

I'm already comfortable with x11vnc under OpenBSD, plus Xephyr, but
they both use an existing X display. After studying xenodm(1),
Xvfb(1), x11vnc(1), and a bunch of other X(1)-related manual pages,
plus tons of experimenting, the solution was actually quite simple.

TL; DR

I could find much on the Internet, list archives, etc., regarding this
specific situation, so here's my solution for a [slow] X11 virtual
display on a vmm(4) OpenBSD guest, accessible via VNC over an SSH
tunnel:

  doas rcctl enable xenodm
  doas rcctl set xenodm flags \
"-server ':0 local /usr/X11R6/bin/Xvfb :0 -screen 1024x768x24 -shmem'"
  doas rcctl start xenodm
  doas pkg_add x11vnc
  doas rcctl enable x11vnc
  doas rcctl start x11vnc

Hope someone else finds this useful down the road,

Morgan

Re: `pkg_add -u` and caching

2023-07-09 Thread Morgan Aldridge 
On Sun, Jul 9, 2023 at 11:11 Morgan Aldridge 
wrote:

> Hi misc@ and Marc,
>
> I have a script for applying all updates/upgrades for upgrading my OpenBSD
> workstation, dev machines, and servers. I'm currently in the process of
> improving it to better support downloading pending updates in advance of
> actual review and installation (see <
> https://github.com/morgant/swupdate-openbsd/issues/14>. I've been
> studying the pkg_add(1) manual, testing, and also reviewing the pkg_add
> Perl source in src/usr.sbin/pkg_add/OpenBSD/, but while really well
> structured and easy to read, the latter does take me longer to grok than
> the former.
>
> I'm hoping you have a quick answer (even if it's 'no') to the following
> question: Does `pkg_add -u` utilize PKG_CACHE other than with the `-n`
> option?
>
> In my testing (on amd64/7.3-stable), the following will check for updates
> and copy packages to `PKG_CACHE`, as described in pkg_add(1):
>
> PKG_CACHE=/home/_swupdate/7.3/packages/amd64 pkg_add -nu
>
> If I delete a cached package from the PKG_CACHE directory, re-executing
> the above command will redownload the package. That's what I was hoping
> for. I'm not quite sure whether some of the packages are being
> re-downloaded by just looking at file modification dates (unfortunately,
> `-v` doesn't note downloads, nor cache mis/hit.)
>
> The following seems to try to update packages from PKG_CACHE, if passed in
> as PKG_PATH, but -- understandably -- does result in errors that some
> packages (those that didn't need updates or have dependencies that did)
> could not be found:
>
> PKG_PATH=/home/_swupdate/7.3/packages/amd64 pkg_add -u
>
> Naturally, if I append ':installpath' to the above PKG_PATH, it will not
> give such errors:
>
> PKG_PATH=/home/_swupdate/7.3/packages/amd64:installpath pkg_add -u
>
> However, since '-v' also doesn't note which package repository (esp.
> local or not) a package was processed from, I don't know whether it's
> actually preferring the local repository.
>
> Additionally, if I set both PKG_CACHE and PKG_PATH to `pkg_add -u`, it
> doesn't appear that packages are downloaded to PKG_CACHE:
>
> PKG_CACHE=/home/_swupdate/7.3/packages/amd64 
> /home/_swupdate/7.3/packages/amd64
> pkg_add -u
>

Typo. The above command should have been:

PKG_CACHE=/home/_swupdate/7.3/packages/amd64 \
PKG_PATH=/home/_swupdate/7.3/packages/amd64 \
pkg_add -u

This is confirmed by deleting a package from PKG_CACHE and re-executing the
> above, after which the deleted package is still missing from PKG_CACHE. Of
> course, this absolutely feels sketchy to be caching to a package
> repository, but was worth a try.
>

Thanks in advance and please CC me if replying to the list as I'm not
subscribed to misc@.

Morgan

> --
Morgan
---
http://makkintosshu.com/
https://centresteer.com/
https://tobuji.tech/
http://unna.org/

`pkg_add -u` and caching

2023-07-09 Thread Morgan Aldridge 
Hi misc@ and Marc,

I have a script for applying all updates/upgrades for upgrading my OpenBSD
workstation, dev machines, and servers. I'm currently in the process of
improving it to better support downloading pending updates in advance of
actual review and installation (see <
https://github.com/morgant/swupdate-openbsd/issues/14>. I've been studying
the pkg_add(1) manual, testing, and also reviewing the pkg_add Perl source
in src/usr.sbin/pkg_add/OpenBSD/, but while really well structured and easy
to read, the latter does take me longer to grok than the former.

I'm hoping you have a quick answer (even if it's 'no') to the following
question: Does `pkg_add -u` utilize PKG_CACHE other than with the `-n`
option?

In my testing (on amd64/7.3-stable), the following will check for updates
and copy packages to `PKG_CACHE`, as described in pkg_add(1):

PKG_CACHE=/home/_swupdate/7.3/packages/amd64 pkg_add -nu

If I delete a cached package from the PKG_CACHE directory, re-executing the
above command will redownload the package. That's what I was hoping for.
I'm not quite sure whether some of the packages are being re-downloaded by
just looking at file modification dates (unfortunately, `-v` doesn't
note downloads, nor cache mis/hit.)

The following seems to try to update packages from PKG_CACHE, if passed in
as PKG_PATH, but -- understandably -- does result in errors that some
packages (those that didn't need updates or have dependencies that did)
could not be found:

PKG_PATH=/home/_swupdate/7.3/packages/amd64 pkg_add -u

Naturally, if I append ':installpath' to the above PKG_PATH, it will not
give such errors:

PKG_PATH=/home/_swupdate/7.3/packages/amd64:installpath pkg_add -u

However, since '-v' also doesn't note which package repository (esp.
local or not) a package was processed from, I don't know whether it's
actually preferring the local repository.

Additionally, if I set both PKG_CACHE and PKG_PATH to `pkg_add -u`, it
doesn't appear that packages are downloaded to PKG_CACHE:

PKG_CACHE=/home/_swupdate/7.3/packages/amd64
/home/_swupdate/7.3/packages/amd64
pkg_add -u

This is confirmed by deleting a package from PKG_CACHE and re-executing the
above, after which the deleted package is still missing from PKG_CACHE. Of
course, this absolutely feels sketchy to be caching to a package
repository, but was worth a try.

Thanks in advance,

Morgan
-- 
Morgan
---
http://makkintosshu.com/
https://centresteer.com/
https://tobuji.tech/
http://unna.org/