plackup and httpd
Not sure if I'm just dense, but it took awhile to figure this out. So I'm just
posting here to
help out the next person that needs to know and happens upon this in the
archives.
doas plackup -s FCGI --listen /var/www/run/psgi.sock myapp.psgi
#/etc/httpd.conf
location "/*" {
fastcgi socket "/run/psgi.sock"
}
If anyone has any advice to improve upon this please share.
Thanks,
Edgar
Icinga2 with httpd
Hi, I'm setting up Icinga2-web with base httpd.
I'm new to web applications so I'm not sure how to translate pkg/READM nginx
config to httpd.conf.
Especially I don't know the equivalent of try_files.
This is my httpd.conf (nginx conf in comments):
server "10.10.0.20" {
listen on * port 80
block return 302 "https://$HTTP_HOST$REQUEST_URI;
}
server "10.10.0.20" {
listen on * tls port 443
tls {
key "/etc/ssl/private/10.10.0.20.key"
certificate "/etc/ssl/10.10.0.20.crt"
}
location "/nfsen/*.php" {
root "/htdocs"
directory index nfsen.php
fastcgi socket "/run/php-fpm_nfsen.sock"
}
# The try_files directive can be used to check whether the specified
# file or directory exists; NGINX makes an internal redirect if it
# does, or returns a specified status code if it doesn't.
#
# location ~ ^/icingaweb2/index\.php(.*)$ {
# fastcgi_pass unix:run/php-fpm-icingaweb2.sock;
# fastcgi_index index.php;
# include fastcgi_params;
# fastcgi_param SCRIPT_FILENAME /icinga-web2/public/index.php;
# fastcgi_param ICINGAWEB_CONFIGDIR /etc/icingaweb2;
# fastcgi_param REMOTE_USER $remote_user;
# }
#
# location ~ ^/icingaweb2(.+)? {
# alias /var/www/icinga-web2/public;
# index index.php;
# try_files $1 $uri $uri/ /icingaweb2/index.php$is_args$args;
# }
#
location match "^/icingaweb2/index\.php(.*)$" {
root "/icinga-web2"
fastcgi socket "/run/php-fpm_icingaweb2.sock"
fastcgi param SCRIPT_FILENAME "/icinga-web2/public/index.php"
fastcgi param ICINGAWEB_CONFIGDIR "/etc/icingaweb2"
}
location match "^/icingaweb2(.+)?" {
root "/icingaweb2/public/index.php"
}
}
Re: boot stops on macppc
On Mon, Sep 16, 2019 at 05:35:49PM +0200, Jan Stary wrote: > On Sep 14 12:58:39, h...@stare.cz wrote: > > This is current/macppc on an old macmini - dmesg below. > > (Putting old hw to work with OpenBSD is a joy; > > plus this is my only macppc test machine.) > > > > At boot(8) time, it stops at the boot prompt saying > > > > >> OpenBSD/macppc BOOT 1.7 > > /bsd.upgrade is not u+x > > /pci@f400/ata-6@d/disk@1:/etc/boot.conf: line too long > > boot> > > booting /pci@f400/ata-6@d/disk@1:/bsd/: > > /pci@f400/ata-6@d/disk@1:/bsd/: inappropriate file type or format > > failed(12304). will try /bsd > > boot> > > booting /pci@f400/ata-6@d/disk@1:/bsd/: > > /pci@f400/ata-6@d/disk@1:/bsd/: inappropriate file type or format > > failed(12304). will try /bsd > > Turning timeout off > > boot> > > > > Doing a manual > > > > boot> boot hd:/bsd > > > > boots just fine, and everything works. > > > > There is no /bsd.upgrade, and this is not a boot after an upgrade. > > I don't have /etc/boot.conf, so which line is too long? > > Why is /pci@f400/ata-6@d/disk@1:/bsd/ considered inappropriate? > > > > One thing i *suspect* is disk numbering confusion: > > I removed the builtin CD drive (because it got broken). > > Note the bootpath: /pci@f400/ata-6@d/disk@0:/bsd > > at the very end of boot messages (disk@0 vs disk@1). > > > > Looking at 'devalias' in the machine's OpenFirmware, > > /pci@f400/ata-6@d/disk@1 is 'hd'; and 'hd:/bsd' is the default, > > so I am puzzled why that's what works as a manual command, > > but not as a default. > > Actually, no; excuse my tired eyes. > > In the machine's devalias, > 'hd' is /pci@f400/ata-6@d/disk@0 and > 'cd' is /pci@f400/ata-6@d/disk@1 . > > The CD drive is not even physically there, > so hd:,ofwboot must be booting from the hd (disk@0); > but that information is somehow lost along the way > from ofwboot to boot(8), who attempts to boot disk@1:/bsd > > How can I help debug this? Hi, I'm writing this twice since I first decided not to continue but then I decided I may as well say something even if it's wrong, to help you out. When you say default is "hd:/bsd" I have taken a look at the INSTALL file for macppc, and it says: > Autobooting OpenBSD/macppc It is possible to automatically boot into OpenBSD (selectably into Mac OS) by setting up the following: setenv auto-boot? true setenv boot-device hd:,ofwboot [to save the results into NVRAM] reset-all <- So I guess you have your boot-device variable set to that, you can also try setting it to "hd:,ofwboot /bsd" it won't make a diff I think. You can check with printenv to see what this environment variable is set to. https://ftp.openbsd.org/pub/OpenBSD/6.5/macppc/INSTALL.macppc is the INSTALL document that has more. If you need to debug further, the code for ofwboot is in /usr/src/sys/arch/macppc/stand Interesting to me was the "parsename()" function in ofdev.c, but I'm code dyslexic so it takes more time than just quickly looking over it as I just did. I don't know if that will solve your problem. Regards, -peter > > Jan > > > > > I tried putting 'boot hd:/bsd' into /etc/boot.conf > > (so that I can do remote reboots), but boot(8) stops > > with the very same messages. > > > > > > Jan > > > > > > This is the current dmesg. I have had the same problem > > with previous versions - previous dmesgs are available > > at http://stare.cz/dmesg/ as apple-macmini-7447A.* > > > > [ using 1289152 bytes of bsd ELF symbol table ] > > console out [ATY,RockHopper2_A] console in [keyboard], using USB > > using parent ATY,RockHopper2Paren:: memaddr 9800, size 800 : > > consaddr 9c008000 : ioaddr 9002, size 2: width 1920 linebytes 2048 > > height 1080 depth 8 > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > The Regents of the University of California. All rights reserved. > > Copyright (c) 1995-2019 OpenBSD. All rights reserved. > > https://www.OpenBSD.org > > > > OpenBSD 6.6-beta (GENERIC) #0: Wed Sep 11 10:56:40 CEST 2019 > > h...@ppc.stare.cz:/usr/src/sys/arch/macppc/compile/GENERIC > > real mem = 1073741824 (1024MB) > > avail mem = 1027039232 (979MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root: model PowerMac10,2 > > cpu0 at mainbus0: 7447A (Revision 0x102): 1499 MHz: 512KB L2 cache > > mem0 at mainbus0 > > spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0 > > memc0 at mainbus0: uni-n rev 0xd2 > > "hw-clock" at memc0 not configured > > kiic0 at memc0 offset 0xf8001000 > > iic0 at kiic0 > > mpcpcibr0 at mainbus0 pci: uni-north > > pci0 at mpcpcibr0 bus 0 > > pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 > > agp at pchb0 not configured > > radeondrm0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01 > > drm0 at radeondrm0 > > radeondrm0: irq 48 > > mpcpcibr1 at mainbus0 pci: uni-north > > pci1 at mpcpcibr1 bus 0 > > macobio0 at pci1 dev 23 function 0 "Apple Intrepid"
Re: boot stops on macppc
On Sep 14 12:58:39, h...@stare.cz wrote: > This is current/macppc on an old macmini - dmesg below. > (Putting old hw to work with OpenBSD is a joy; > plus this is my only macppc test machine.) > > At boot(8) time, it stops at the boot prompt saying > > >> OpenBSD/macppc BOOT 1.7 > /bsd.upgrade is not u+x > /pci@f400/ata-6@d/disk@1:/etc/boot.conf: line too long > boot> > booting /pci@f400/ata-6@d/disk@1:/bsd/: > /pci@f400/ata-6@d/disk@1:/bsd/: inappropriate file type or format > failed(12304). will try /bsd > boot> > booting /pci@f400/ata-6@d/disk@1:/bsd/: > /pci@f400/ata-6@d/disk@1:/bsd/: inappropriate file type or format > failed(12304). will try /bsd > Turning timeout off > boot> > > Doing a manual > > boot> boot hd:/bsd > > boots just fine, and everything works. > > There is no /bsd.upgrade, and this is not a boot after an upgrade. > I don't have /etc/boot.conf, so which line is too long? > Why is /pci@f400/ata-6@d/disk@1:/bsd/ considered inappropriate? > > One thing i *suspect* is disk numbering confusion: > I removed the builtin CD drive (because it got broken). > Note the bootpath: /pci@f400/ata-6@d/disk@0:/bsd > at the very end of boot messages (disk@0 vs disk@1). > > Looking at 'devalias' in the machine's OpenFirmware, > /pci@f400/ata-6@d/disk@1 is 'hd'; and 'hd:/bsd' is the default, > so I am puzzled why that's what works as a manual command, > but not as a default. Actually, no; excuse my tired eyes. In the machine's devalias, 'hd' is /pci@f400/ata-6@d/disk@0 and 'cd' is /pci@f400/ata-6@d/disk@1 . The CD drive is not even physically there, so hd:,ofwboot must be booting from the hd (disk@0); but that information is somehow lost along the way from ofwboot to boot(8), who attempts to boot disk@1:/bsd How can I help debug this? Jan > I tried putting 'boot hd:/bsd' into /etc/boot.conf > (so that I can do remote reboots), but boot(8) stops > with the very same messages. > > > Jan > > > This is the current dmesg. I have had the same problem > with previous versions - previous dmesgs are available > at http://stare.cz/dmesg/ as apple-macmini-7447A.* > > [ using 1289152 bytes of bsd ELF symbol table ] > console out [ATY,RockHopper2_A] console in [keyboard], using USB > using parent ATY,RockHopper2Paren:: memaddr 9800, size 800 : consaddr > 9c008000 : ioaddr 9002, size 2: width 1920 linebytes 2048 height 1080 > depth 8 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 6.6-beta (GENERIC) #0: Wed Sep 11 10:56:40 CEST 2019 > h...@ppc.stare.cz:/usr/src/sys/arch/macppc/compile/GENERIC > real mem = 1073741824 (1024MB) > avail mem = 1027039232 (979MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root: model PowerMac10,2 > cpu0 at mainbus0: 7447A (Revision 0x102): 1499 MHz: 512KB L2 cache > mem0 at mainbus0 > spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0 > memc0 at mainbus0: uni-n rev 0xd2 > "hw-clock" at memc0 not configured > kiic0 at memc0 offset 0xf8001000 > iic0 at kiic0 > mpcpcibr0 at mainbus0 pci: uni-north > pci0 at mpcpcibr0 bus 0 > pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 > agp at pchb0 not configured > radeondrm0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01 > drm0 at radeondrm0 > radeondrm0: irq 48 > mpcpcibr1 at mainbus0 pci: uni-north > pci1 at mpcpcibr1 bus 0 > macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 > openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE > macgpio0 at macobio0 offset 0x50 > "modem-reset" at macgpio0 offset 0x1d not configured > "modem-power" at macgpio0 offset 0x1c not configured > macgpio1 at macgpio0 offset 0x9: irq 47 > "programmer-switch" at macgpio0 offset 0x11 not configured > "gpio5" at macgpio0 offset 0x6f not configured > "gpio6" at macgpio0 offset 0x70 not configured > "extint-gpio15" at macgpio0 offset 0x67 not configured > "escc-legacy" at macobio0 offset 0x12000 not configured > zs0 at macobio0 offset 0x13000: irq 22,23 > zstty0 at zs0 channel 0 > zstty1 at zs0 channel 1 > aoa0 at macobio0 offset 0x1: irq 30,1,2 > "timer" at macobio0 offset 0x15000 not configured > adb0 at macobio0 offset 0x16000 > apm0 at adb0: battery flags 0x0, 0% charged > piic0 at adb0 > iic1 at piic0 > maxtmp0 at iic1 addr 0xc8: max6642 > kiic1 at macobio0 offset 0x18000 > iic2 at kiic1 > wdc0 at macobio0 offset 0x2 irq 24: DMA > audio0 at aoa0 > ohci0 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29, > version 1.0, legacy support > ohci1 at pci1 dev 27 function 0 "NEC USB" rev 0x43: irq 63, version 1.0 > ohci2 at pci1 dev 27 function 1 "NEC USB" rev 0x43: irq 63, version 1.0 > ehci0 at pci1 dev 27 function 2 "NEC USB" rev 0x04: irq 63 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0
Re: authpf unable to exit ssh without control C
On 9/15/19 7:31 AM, shadrock uhuru wrote: > hi everyone > i can login with authpf but unable to exit or control D out of the ssh > session > the only way out is to control C which also kills any other ordinary ssh > user connected to the server > my authpf user has authpf as its login shell and login class, > is this normal behaviour ? > shadrock > If I understand your request, you want someone to log into your system, which brings up authpf, and you want them to be able to do something to exit to a shell prompt on that server and still leave the authpf rules in place? That's not the way authpf was designed. The idea is that when authpf is invoked, it activates certain rules, presumably regarding the IP address in question, and when authpf exits, it removes those changes. Connect to authpf, now you can access the web site, or FTP or whatever it is you need, terminate authpf, and no one else at your IP can do those things. If you are letting these same users access the shell prompt, your usage is not as paranoid as authpf was designed to deal with, it's probably not the right tool for the job, or your expectations are wrong. I run a private IRC server, which is blocked on the 'net by PF, but as all the users are people I know in real life and friends, I trust them to be able to activate their own IP addresses, so I just wrote a simple (and surely insecure) script to add that user's IP address to the PF table that permits them access to the system. What this doesn't do (and I'm not sure how you expect to do this) is clear the connections when they leave. In my case, I don't care -- the odds that after Fred gets a new IP address that his old IP address will end up in the hands of someone wanting to have access to my IRC server for malicious reasons (and they find it!) is pretty small. But that might not be your use case. If you need to close those openings...you had best think hard about how you expect that to happen. Nick.
Re: openup service question
On Mon, 16 Sep 2019 at 09:13:13 +, rsyk...@disroot.org wrote: > Dear list, > > > I have been using the "openup" service to keep my amd64 machine updated > to the latest stable, i.e. 6.5, available at > > https://www.mtier.org/solutions/apps/openup/ > > Recently I get: > > odin# ./openup > > ===> Checking for openup update > ===> Installing/updating syspatches > Get/Verify syspatch65-011_expat.tgz 100% |**| 588 KB00:00 > > Installing patch 011_expat > Errata can be reviewed under /var/syspatch > ===> Updating package(s) > https://stable.mtier.org/updates/6.5/amd64/: ftp: Error retrieving file: 401 > Unauthorized > https://stable.mtier.org/updates/6.5/amd64/: empty > > If anybody here understands what is happening to me, I'd be grateful to know. > The site claims the support for the most recent release is free. Yet, ... > > I tried to contact their support twice, but got no reply. > > > Thank you for any comments! > Ruda > > > PS.: Does using openup convey any advantage over running "syspatch" and > "pkg_add -u" on amd64? > Now you can switch: https://undeadly.org/cgi?action=article;sid=20190814112133 -- - gonzalo
openup service question
Dear list, I have been using the "openup" service to keep my amd64 machine updated to the latest stable, i.e. 6.5, available at https://www.mtier.org/solutions/apps/openup/ Recently I get: odin# ./openup ===> Checking for openup update ===> Installing/updating syspatches Get/Verify syspatch65-011_expat.tgz 100% |**| 588 KB00:00 Installing patch 011_expat Errata can be reviewed under /var/syspatch ===> Updating package(s) https://stable.mtier.org/updates/6.5/amd64/: ftp: Error retrieving file: 401 Unauthorized https://stable.mtier.org/updates/6.5/amd64/: empty If anybody here understands what is happening to me, I'd be grateful to know. The site claims the support for the most recent release is free. Yet, ... I tried to contact their support twice, but got no reply. Thank you for any comments! Ruda PS.: Does using openup convey any advantage over running "syspatch" and "pkg_add -u" on amd64?
Re: How can I remove sets installed by sysupgrade?
> > My reasoning behind NOT installing the X, Comp and Game sets have > little > to do with saving space, although I am using an 8GB SSD. I learned in my > research that one of the most fundamental ways to improve network/system > security is to minimize the attack surface by not installing unneeded > software. If it isn't installed, any potential vulnerabilities, known or > not, are irrelevant. > What is not irrelevant is the person/program that somehow has a shell on your box can paste the required 500 bytes of hex data into "openssl base64 -d" to get a binary on your system, so removing the Comp set is one of those "it would be super hard for me to imagine what I need to run a local privilege escalation so it must require all these tools" whereas the hackers that do own other boxes will already have the short_ASM_sequence* tested locally and only need to get those over the same path the exploit took in order to get a better foothold on your machine. So removing comp sets just mean you can't patch locally when a scary advisory comes out, it also means you need to special-case your sysupgrades and those two choices will probably mean you will stay vulnerable for a longer time just because you hoped leaving cc(1),as(1) and battlestar(6) out of the box will "save" you. Yes, I can imagine some few scenarios where it might, but as the other reply you already got says, when you make your own box a surprise to administer and reason about, you are making it worse already so the comparisons about what choice is safer doesn't even start from the same level. *) SEE ALSO: https://en.wikipedia.org/wiki/SQL_Slammer -- May the most significant bit of your life be positive.
Re: unbound/dns issue (malformed packets?)
Hi Joe, The domain whatsapp.com doesn't guarantee integrity to you (they have dnssec turned off, at least last I checked). It's possible that someone got in your middle and inserted a bogus record. This being said I'M ignorant to the fact that nlnetlabs have changed their internal database, so this is likely not a corruption issue but stems from the wire. Hopefully my 2 cents are helpful. -peter On Sun, Sep 15, 2019 at 06:23:28PM -0700, Joe Barnett wrote: > I've been seeing some issues which I believe to be related to dns/resolving. > The short of it is that the results of > > # dig web.whatsapp.com > > start out as: > > ; <<>> DiG 9.4.2-P2 <<>> web.whatsapp.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57665 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;web.whatsapp.com. IN A > > ;; ANSWER SECTION: > web.whatsapp.com. 3595IN CNAME mmx-ds.cdn.whatsapp.net. > mmx-ds.cdn.whatsapp.net. 55 IN A 31.13.70.49 > > ;; Query time: 6 msec > ;; SERVER: 192.168.254.254#53(192.168.254.254) > ;; WHEN: Sun Sep 15 14:46:24 2019 > ;; MSG SIZE rcvd: 87 > > which seems reasonable (and functional), but then soon become: > > ;; Warning: Message parser reports malformed message packet. > > ; <<>> DiG 9.4.2-P2 <<>> web.whatsapp.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40939 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;web.whatsapp.com. IN A > > ;; ANSWER SECTION: > web.whatsapp.com. 3528IN CNAME mmx-ds.cdn.whatsapp.net. > mmx-ds.cdn.whatsapp.net. 30772 RESERVED0 A \# 4 1F0D4631 > > ;; Query time: 2 msec > ;; SERVER: 192.168.254.254#53(192.168.254.254) > ;; WHEN: Sun Sep 15 14:47:31 2019 > ;; MSG SIZE rcvd: 87 > > At which point I am no longer able to access web.whatsapp.com. Given that > whatsapp is a facebook property, I tried the above against facebook.com, > www.facebook.com, instagram.com, and www.instagram.com as well. With the > exception of instagram.com, the other three (facebook, www.facebook, > www.instagram) return a hex (?) formatted version of the IP address, similar > to what is seen in the later of the above examples. My thinking is (or was) > that there are some issues relating to fb's DNS. From outside of my > network, however, other resolvers seem to be able to continually resolve the > above names correctly. I don't know what those resolvers are, but > specifically I am referring to whatever Linode and DigitalOcean use in the > nameservers they provide to their basic Linux vms (I am using the default > network config in my vms at Linode and DigitalOcean). I have a suspicion > that Linode uses unbound, but I do not know how to verify that. Oh, as far > as I can tell, those facebook-family names *seem* to be the only names for > which I see this behavior -- all other names that I have tried to run > through dig (and nslookup) seem to return reasonable and seemingly correct > results. > > A bit about my (home) network. I have Cox cable internet service, an Arris > SBG7580-AC, and an OpenBSD 6.5 machine that sits between the modem and the > rest of the network. I(we) do use the modem in router mode (but without > using the built-in WiFi) as my wife's work git-up consists of a > pre-configured black-box of a Juniper device. Not wanting that device in > the rest of our network, I set the modem to "RoutedWithNAT" and the two > network devices plug into the modem, but provide two separate networks. For > remote ingress into the rest of the network, I set the modem's DMZ to point > to the OpenBSD box. My pf.conf does the usual small network stuff including > NAT, a bit of redirection, etc. It has changed very little in the past > several years. My unbound.conf is also nearly unchanged since I first set > it up when OpenBSD dropped bind and replaced it with unbound. My OpenBSD > machine provides name resolving for the rest of the network. My > unbound.conf follows: > > server: > interface: 0.0.0.0 > interface: ::1 > do-ip6: no > > access-control: 0.0.0.0/0 refuse > access-control: 127.0.0.0/8 allow > access-control: 192.168.0.0/16 allow > access-control: 10.0.0.0/24 allow > access-control: 172.16.0.0/24 allow > access-control: ::0/0 refuse > access-control: ::1 allow > > hide-identity: yes > hide-version: yes > > # ftp://FTP.INTERNIC.NET/domain/named.cache > root-hints: "/var/unbound/etc/named.cache" > > # uncomment to enable DNSSEC > auto-trust-anchor-file: "/var/unbound/db/root.key" > > ### various local-zone, local-data, and local-date-ptr ### > > remote-control: > control-enable: yes > control-use-cert: yes >
