serial console works only if system is booted from it
Hi, I tried to set up serial console on my system in addition to the regular monitor/keyboard, and I am running into a problem. I want to have both local monitor and serial console. This is what I have tried. The system is booted with console on the attached monitor/keyboard. I change the line in /etc/ttys for tty00 to enable getty on tty00: tty00 "/usr/libexec/getty std.9600" vt220 on secure I reloaded init after the change by sending SIGHUP to it. I can see getty process running for tty00. Terminal emulator connected to the serial port shows nothing. Now I reboot the system and type "set tty com0" at the boot prompt on the locally attached keyboard/monitor. The boot process continues on the serial port and I see all output on the terminal emulator. After boot finishes, I have login prompt both on the serial port and on the monitor/keyboard. Login works from both. It appears that serial console works for me only if I booted the system from it. I am not able to activate serial console if the system was not booted from it. Is this expected behavior or am I doing something wrong here? I can see a difference in dmesg between boot on serial console and regular monitor/keyboard. Boot on serial has com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com0: console com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo com2 at acpi0 UAR3 addr 0x3e8/0x8 irq 10: ns16550a, 16 byte fifo com3 at acpi0 UAR4 addr 0x2e8/0x8 irq 11: ns16550a, 16 byte fifo Boot on monitor/keyboard has com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo com2 at acpi0 UAR3 addr 0x3e8/0x8 irq 10: ns16550a, 16 byte fifo com3 at acpi0 UAR4 addr 0x2e8/0x8 irq 11: ns16550a, 16 byte fifo Full dmesg is below: OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8486543360 (8093MB) avail mem = 8212041728 (7831MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec120 (16 entries) bios0: vendor American Megatrends Inc. version "BASIIA06" date 03/23/2021 bios0: NF792I NF792I acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT CSRT acpi0: wakeup devices XHC1(S4) HDEF(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) BRC1(S0) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1600.43 MHz, 06-4c-04 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 80MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1600.02 MHz, 06-4c-04 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1600.02 MHz, 06-4c-04 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz, 1600.02 MHz, 06-4c-04 cpu3: 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpiprt0 at
Re: CIAM recommendation
Thanks for the response Tobias. Hope you can share with me your references on setting up a CIAM running on OpenBSD. I ran into FusionAuth and liked what I saw on client self-service registration and web-based user identity management; though they are Java-based, it seems that their disappointing definition of open source is that it runs on Linux. Thanks. On Sun, Jul 24, 2022 at 8:39 PM Tobias Fiebig < tob...@reads-this-mailinglist.com> wrote: > Heho, > I think getting the basis going is not too hard; There is LDAP and iirc > also krb5 in base (if not, it is in ports), and you can always shoot for AD > with smb4. > > The bigger problem, though, is most likely getting a proper 'web-ish' SSO > provider for sth. like SAML or OpenID going. IIRC there are some PHP > implementations running against an LDAP fine; But the question then is > whether OpenBSD provides that much benefit if SSO goes through some random > PHP app with a questionable update record. > > For the more common SAML/OpenID providers, you probably run into the issue > that most of these apps are either a) build to be funny appliances, or b) > build to run in _some_ form of docker-ish environment (or, as I call it: > The enterprise problem)... > > I am planning to $somewhen setup something similar with OpenBSD and will > be happy to share docs (if I get around to it); But that will most likely > also be 'not safe for production' anyway... > > With best regards, > Tobias > > > > > -Original Message- > From: owner-m...@openbsd.org On Behalf Of Tito > Mari Francis Escaño > Sent: Sunday, 24 July 2022 07:11 > To: misc@openbsd.org > Subject: CIAM recommendation > > Hi everyone, > Can you please recommend package(s) I can setup on OpenBSD to create a > CIAM or customer identity and access management system? This is to provide > SSO between enterprise applications. While it's easy to go for Linux > option, I prefer to build on top of the security offered by OpenBSD from > the ground up. > Would appreciate your pointers on this. > Thank you. > >
cdn.openbsd.org stale bsd.mp for amd64 snaps
Hello, The amd64 snapshots on cdn.openbsd.org have a stale bsd.mp file, which is making sysupgrades fail. The other files are up-to-date. ftp.openbsd.org has the correct bsd.mp, so it appears to be a caching issue with Fastly. Might need to force a refresh? Thanks, -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: No login prompt on console ttyC0 after boot when using "set tty com0"
> -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Andrew Daugherity > > > > Hello > > I was wondering if there is anything I could do to help figure this > out. > > I do not have the requisite knowledge to even begin to understand why > the > > kernel does not configure the vga output when boot.conf redirects to > com0. > > Look for a "redirection after boot" setting in your BIOS and try > disabling that. The behavior you've described of both physical and > serial consoles working at the boot prompt _without_ 'set tty com0' > seems to indicate the BIOS is still handling redirection from > keyboard/video to serial, and my guess is that when OpenBSD > initializes the port for a serial console, it causes something in the > BIOS-linked local keyboard/vga to go wonky (wsdisplay at vga1 not > configured). Thanks for suggestion. The BIOS does, in fact, redirect output to both the local console and a serial console at startup. This makes the BIOS configuration available on the serial console and the local monitor. After the BIOS screen, if "set tty com0" is _not_ included, then the boot dmesg is displayed on the local monitor, the serial goes silent, and at the end of openBSD boot, a login prompt is available on both serial console and local monitor. If "set tty com0" is _set_, then, after the BIOS page shows on both the serial console and local monitor, the boot dmesg scrolls on the serial console, and then login prompt is available on the serial console. The local monitor shows the openBSD boot "redirecting" message, and then nothing more. At the end of boot, there is _no_ login prompt on the local monitor. If I _disable_ the BIOS serial redirection feature, but keep "set tty com0" _set_, I see the following: - the local monitor shows: BIOS screen, openBSD start text ending with "redirecting to...", and that is all. No login prompt at the end of boot - the serial console shows: _no_ BIOS screen, then the openBSD boot and dmesg information, and ends with a login prompt The only change which, apparently, disables the configuration of ttyC0 during/after boot is setting "set tty com0" in boot.conf. However, the local monitor is alive, since it gets the BIOS information and the initial openBSD boot message, which suggests that the BIOS is correctly recognizing the monitor/output early in the boot, but then openBSD is unable to configure it later. Again, the only change that seems to make a difference is setting "set tty com0" or not. The console redirection option in the BIOS for the pre-boot/BIOS information does not affect this. > > Note that in UEFI mode, "wsdisplay at vga1 not configured" would be > expected, as efifb takes over: > > $ dmesg|egrep 'wsdisplay|fb|vga|com[0-9]' > vga1 at pci7 dev 0 function 0 "Matrox MGA G200eR" rev 0x01 > wsdisplay at vga1 not configured > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo > com1: console > efifb0 at mainbus0: 1280x1024, 32bpp > wsdisplay0 at efifb0 mux 1 > wsdisplay0: screen 0-5 added (std, vt100 emulation) > > You might give UEFI mode a try, to see if efifb works better than the > vga console. Redirection after boot is probably the more important > setting though. > The system is installed on one full disk openBSD partition. I believe (not 100% sure) that changing to UEFI would require a small EFI partition (which would mean changing the fdisk partition and disklabel without destroying the software RAID), which is not a challenge I can take on right now. But, I will keep it in mind. > Note that the login prompt appearing on a console (spawning a getty as > configured in /etc/ttys) and the bootloader/kernel console device are > independent settings. > Yes, which is my confusion. Both the serial console (tty00) and the local terminal (ttyC0) are set in ttys: head -n 20 /etc/ttys # # $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $ # # name getty typestatus comments # console "/usr/libexec/getty std.9600" vt220 off secure ttyC0 "/usr/libexec/getty std.9600" vt220 on secure ttyC1 "/usr/libexec/getty std.9600" vt220 on secure ... ttyCb "/usr/libexec/getty std.9600" vt220 off secure tty00 "/usr/libexec/getty autologin" vt220on secure tty01 "/usr/libexec/getty std.9600" unknown off (Note, the "autologin" type for getty is an addition in my gettytab which allows getty to spawn a login prompt that does not require the long, complex password to login when at the serial console.) > -Andrew Thanks Ted
Re: CIAM recommendation
Heho, I think getting the basis going is not too hard; There is LDAP and iirc also krb5 in base (if not, it is in ports), and you can always shoot for AD with smb4. The bigger problem, though, is most likely getting a proper 'web-ish' SSO provider for sth. like SAML or OpenID going. IIRC there are some PHP implementations running against an LDAP fine; But the question then is whether OpenBSD provides that much benefit if SSO goes through some random PHP app with a questionable update record. For the more common SAML/OpenID providers, you probably run into the issue that most of these apps are either a) build to be funny appliances, or b) build to run in _some_ form of docker-ish environment (or, as I call it: The enterprise problem)... I am planning to $somewhen setup something similar with OpenBSD and will be happy to share docs (if I get around to it); But that will most likely also be 'not safe for production' anyway... With best regards, Tobias -Original Message- From: owner-m...@openbsd.org On Behalf Of Tito Mari Francis Escaño Sent: Sunday, 24 July 2022 07:11 To: misc@openbsd.org Subject: CIAM recommendation Hi everyone, Can you please recommend package(s) I can setup on OpenBSD to create a CIAM or customer identity and access management system? This is to provide SSO between enterprise applications. While it's easy to go for Linux option, I prefer to build on top of the security offered by OpenBSD from the ground up. Would appreciate your pointers on this. Thank you.
Re: snapshot packages
On 2022-07-23, not jacinda ardern wrote: > Is there a way to see the build status of the different architectures > for snapshot packages, eg via a continuous integration pipeline or > somesuch No > I noticed that the current snapshots seem to have moved to libz-7.0 in > the last few days but the packages haven't quite caught up yet on all > architectures, which leads to what seems like a lot of errors on pkg_add > -u after sysupgrade -s on some platforms (b/c the packages expected > libz-6.1, which seems to have been eaten during the most recent snapshot > tgzs, at least on amd64, or perhaps I'm a doofus). Generally, amd64 i386 sparc64 arm64 will show up every 3-6 days or so, others are slower. Normally we tried to get builds done asap after library bumps but due ti some other changes in the base OS at around the same time which we've had to handle in ports, it's been a bit slower than usual this time. If you're using -current it's a good idea to watch for library version bumps on source-changes so you can be aware that you may need to wait for new packages. -- Please keep replies on the mailing list.
