Re: loading DBD-Pg under base httpd, works but it's wrong way
On Fri, May 01, 2020 at 01:11:12AM -0400, Chris Bennett wrote: > On Thu, Apr 30, 2020 at 08:16:05PM -0700, Andrew Hewus Fresh wrote: > > I'm assuming this is using slowcgi, is that correct? > > Yes > > > > > Depending on your use case, it might be easier to have a separate > > slowcgi process for just this script and then add OpenBSD::Pledge(3p) > > and possibly OpenBSD::Unveil(3p) to limit what the script can do. This > > could work with slowcgi's `-u` flag to have this script run as a > > specific user. > > > > I have several domains. Some are running very limited scripts. > > For several, just some very basic stuff. Pledge and Unveil would work > great for those. I'll check into that. They write files and send emails. Do note that httpd expects that slowcgi will be chrooted to the same place as httpd and sets some of the FCGI_PARAMS based on finding the scripts in that chroot. It's possible to make that work with a "phantom" directory structure in the httpd chroot that mirrors the scripts you will be running with slowcgi. They don't need to be the full files, empty files that are set as executable work fine for faking the check. With that hack and messing with "root" and "rewrite request" in the location served by that fastcgi should allow you to get the information to the script in the necessary format. Another option is a Plack Middleware that rewrites those variables as necessary. Running slowcgi with the debug (-d) flag is very informative. > One site has a ton of complicated scripts, many in mod_perl that I want > to ditch. You may want to look at some of the options for modules that fake being mod_perl and run under Plack, which has a FastCGI handler that works well with httpd(8). https://metacpan.org/search?q=plack+apache https://metacpan.org/pod/Plack::Handler::FCGI > I am also forking a forum software that's been dropped. > It makes a lot of sense to pull all of those perl scripts into a single > wrapper. It reads/writes to postgresql, sends and receives emails and > can optionally write files. Pledge and Unveil sound like good optional > settings. My preference is to make it portable after ditching some > security issues and dropping mod_perl 1 from it, etc. If those scripts were ported from CGI to mod_perl and not changed significantly, I have had good experience with CGI::Emulate::PSGI which will load those CGIs into a persistent process. The benefit of having been ported to mod_perl is that someone probably created an "init" function that resets all the state necessary at the beginning of the request. https://metacpan.org/pod/CGI::Emulate::PSGI If they were written specifically targeting mod_perl 1, you probably have a slog ahead of you and I don't envy you the task. > This has all been a bit frustrating, but having worked things out, now > it's fun! That's computers for you. l8rZ, -- andrew - http://afresh1.com Real programmers don't document. If it was hard to write, it should be hard to understand.
FAQ - Multimedia - Recording Audio Samples: 'field...does not exist'
The FAQ - Multimedia - Recording Audio Samples suggests the following mixerctl(1) parameters: inputs.mic.mute=off inputs.mic.preamp=on inputs.mic.source=mic0 record.source=mic record.volume=255,255 record.volume.mute=off record.mic=255 record.mic.mute=off However, most of these parameters don't appear to be supported: $ doas mixerctl inputs.mic.mute=off mixerctl: field inputs.mic.mute does not exist $ doas mixerctl inputs.mic.preamp=on mixerctl: field inputs.mic.preamp does not exist $ doas mixerctl inputs.mic.source=mic0 mixerctl: field inputs.mic.source does not exist $ doas mixerctl record.source=mic mixerctl: field record.source does not exist $ doas mixerctl record.volume=255,255 record.volume: 255,255 -> 255,255 $ doas mixerctl record.mic.mute=off mixerctl: field record.mic.mute does not exist $ doas mixerctl record.mic=255 mixerctl: field record.mic does not exist $ doas mixerctl record.mic.mute=off mixerctl: field record.mic.mute does not exist My current audio system mixing variables: $ doas mixerctl inputs.dac-0:1_mute=off inputs.dac-0:1=222,222 inputs.dac-2:3_mute=off inputs.dac-2:3=222,222 inputs.beep=108 record.adc-2:3_source=mic3 record.adc-2:3_mute=off record.adc-2:3=240,240 record.adc-0:1_source=sel record.adc-0:1_mute=off record.adc-0:1=240,240 record.adc-4:5_source=sel record.adc-4:5_mute=off record.adc-4:5=240,240 inputs.sel_source=mic outputs.sel=126,126 inputs.sel2_source=mic outputs.sel2=126,126 outputs.hp_source=dac-0:1 outputs.hp_boost=off outputs.mic_dir=input-vr80 outputs.mic2_source=dac-0:1 outputs.mic2_dir=input-vr80 outputs.mic2_eapd=on outputs.hp2_source=dac-0:1 outputs.spkr_source=dac-2:3 inputs.mic3=126,126 inputs.mix_source=dac-0:1,dac-2:3 inputs.mix_dac-0:1=126,126 inputs.mix_dac-2:3=126,126 outputs.hp_sense=unplugged outputs.mic_sense=unplugged outputs.mic2_sense=unplugged outputs.hp2_sense=unplugged outputs.spkr_muters=hp,mic2,hp2 outputs.master=255,255 outputs.master.mute=off outputs.master.slaves=dac-0:1,dac-2:3 record.volume=255,255 record.volume.mute=off record.volume.slaves=adc-2:3,adc-0:1,adc-4:5 record.enable=sysctl Am I missing something? azalia(4) lists only the widget types and the form of the mixer item names. Is there a complete list with explanations of mixer classes, widget types, and properties, something like sysctl(2)? In addition to mixerctl (1), I've searched audio(4), audio(9), audioctl(1), sndio(7), sndioctl(1), and /usr/include/sys/audioio.h. Not sure where else to look. Thanks in advance, Gail OpenBSD 6.7-beta (GENERIC.MP) #149: Wed Apr 22 11:17:50 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4156157952 (3963MB) avail mem = 4017577984 (3831MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (65 entries) bios0: vendor LENOVO version "8DET58WW (1.28 )" date 02/14/2012 bios0: LENOVO 4299HB4 acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.25 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2, x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC, MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.92 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2, x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC, MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.92 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2, x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC, MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB
pppoe LCP keepalive timeouts and inet6 default route
My DSL connection, using a modem in "bridge" mode and pppoe(4), suffers from disconnections every few (5 or so) days. The following message is printed in the syslog: pppoe0: LCP keepalive timeout which indicates that several Echo-Requests were not followed by replies, so the kernel considers the connection to be dead and tries to reestablish the PPP session. Perhaps this could be fixed by the ISP, or perhaps it comes from the modem, and perhaps it could be fixed by increasing either MAXALIVECNT or the sec parameter in the relevant timeout_add_sec(9) call in src/sys/net/if_spppsubr.c (currently these are hard-coded but it would be nice to make these parameters accessible through ifconfig(8): see the "bugs" section in sppp(4)). The disconnection itself is not the problem that I want to discuss right now. sppp(4) manages to reconnect (sometimes it takes a few minutes, presumably because the other end is not happy that the previous connection was not properly terminated), and so as long as the reconnections are not too frequent it is not too big of an issue. My main problem is that the default IPv6 route, configured by adding !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 to /etc/hostname.pppoe0 as suggested by the manual, does not survive the reconnection (to be precise, all IPv6 addresses are purged when the new IPv6CP dance succeeds, and so the routes are purged as well). This is surprising because the default IPv4 route does survive the reconnection (route -n monitor tells me that some magic happens with the "special" addresses 0.0.0.0 and 0.0.0.1). Of course running the above route command reinstates the default IPv6 route, but this has to be done manually. Is this problem known? Is it the case for all sppp(4) connections (with IPv6 enabled of course), or even for all similar point-to-point interfaces? If your connection is reliable, you can simply unplug the phone line for about 30 seconds to try to reproduce this issue. A detail that can make my case somewhat particular: for some reason none of the DHCPv6 clients in ports worked for me (even if I temporarily disable the firewall, my "solicit" remain unanswered) but since my ISP informed me of my prefix, I could simply configure the "local" interface of the router with a static IPv6 address, and similarly for rad(8). Fortunately my ISP is routing the IPv6 packets on my line even without prefix delegation. I considered the following possible solutions. 1) The kernel could have a way of remembering the default IPv6 route that was added, like for IPv4. I don't know what kind of complication to the routing code that would entail. 2) I considered using ifstated(8) to add the default route anytime pppoe0 comes up, but this does not seem to be the right event: if I understand correctly, the interface is marked as "up" when the PPP dance succeeds, before any one of the NCP dances succeeds. One could have a little nap between the "up" event and the addition of the default IPv6 route, but that does not seem right. One could add more interface events to ifstated(8), but perhaps that is too complicated for this particular tool? 3) As a temporary measure, I wrote a small program (with a lot of copy-paste from the source of ifstated(8) and route(8), see attachment) that waits for the addition of new route with destination fe80::%pppoe0, and subsequently adds the sought default route. It worked at least once, so I am hopeful that it will work always. I have no doubt that it could be improved (for starters, the name of the interface could be passed as argument). PS: although the route(4) man page was really useful to understand how to talk to the kernel, it does not give all the details to do so (e.g. alignment on "long" for the sockaddrs, the way scope ids are embedded in link-local addresses, and which fields in the sockaddrs are actually used by the kernel). That is not really preventing anyone to interact with the kernel because there are many examples of code in base (sys/net/rtsock.c, sbin/route/*.c, ...), but I thought I would point it out just in case the goal is to have the route(4) man page be self-contained. pppoeroute.c.gz Description: Binary data
Disable snmpd 'private' community
I see that snmpd.conf supports "read-write disabled", but this doesn't seem to _completely_ disable the private community. If I set "read-write disabled" I can still poll values using the 'private' community. Is this a bug or a feature? -Steve S.
Re: Show driver attached to a PCI device
On 01-05-2020 13:49, Andrey Ponomarenko wrote:
Hello,� Is there a way to show driver attached to a PCI device?� The
pcidump utility doesn't show attached drivers.� Thanks.� Andrey�
I think the following should show you something reasonable for the
currently running kernel:
grep "at pci" /var/run/dmesg.boot
This includes devices without attached driver. ("not configured")
Show driver attached to a PCI device
Hello,� Is there a way to show driver attached to a PCI device?� The pcidump utility doesn't show attached drivers.� Thanks.� Andrey�
