Re: mounting ext3 using doas
dmthomp...@gmx.com wrote: > So I tried doas with this "permit nopass me as root cmd mount_ext2fs" > but still no luck. > > So I was hoping for a hand from you kind souls. > > Oh and when I try to mount at command line using doas I get 'syntax error at > line > 7' there's nothing wrong with that line, suggesting the error is on line 7 instead.
Re: Catastrophic
On 27/1/20 11:59 pm, Justin Noor wrote: > I am unable to send any log files or anything. I had to send this > email from a different machine. I can take pictures of log files and > transfer the information, but I'm not sure where to start. A `dmesg` before the crash would at least tell us whether there's problematic hardware/drivers in use. Even though it's not taken at the moment of the crash doesn't mean it's worthless. Has the machine got a serial port? Maybe you could hook that up to a logging terminal emulator on another computer via a null-modem cable? (It may need to be a PCI(e)-connected serial port rather than USB, not many OSes support serial console over USB due to the complexities of USB itself.) Maybe you could configure syslogd(8) to send its logs via UDP to a syslog on another computer? It might not catch the very last log messages, but maybe might capture enough? -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Dell Latitude e6400 OpenBSD Drive Issue
On 2020-02-09 06:58, Michael G Workman wrote: Hello, Shout out to the OpenBSD developers for making a great OS! I was able to install OpenBSD 6.6 on a Dell Latitude e6400 laptop, with a USB Install. Sent the dmesg in already. The installer would not recognize the hard drive, a brand new SSD drive. The solution to that, from stack exchange, was to change the SATA settings in BIOS from IRRTL to AHCI, that fixed the problem. However if my laptop is powered off for a while, the SATA setting changes back to IRRTL instead of AHCI, very annoying, not sure why the BIOS would not make my changes persistent. I think it may be a hardware issue, but just wanted to know if anyone else has encountered this before? Thanks. *Michael G. Workman* (321) 432-9295 michael.g.work...@gmail.com I have run several laptops from that series with OpenBSD. The other replies are correct, your BIOS battery is dead. Unfortunately, on many of the Latitudes, the BIOS battery is of the variety that's embedded in the RTC chip, and is not separately replaceable. Some, however, including - the 6430 for example - have a regular coin cell, albeit wrapped in a proprietary cover with a non-standard connector, but at least is *is* replaceable without insane amounts of work. I have the owner's manuals for many of the 6400 series, email me directly if you can't find the guide to replacing parts for your particular model. -Adam
Re: Missing files on mirror
On 2020-02-08, Mihai Popescu wrote: > Hello, > > I am using ftp2.eu.openbsd.org as a mirror for installing snapshots. Some > files are reported as not found, like nspr-2.4, but they are present on > ftp.openbsd.org. > What could be wrong, a file sync failure? > > Thank you. > ftp2.eu seems a bit flaky at the moment. Maybe try https://mirror.ungleich.ch/pub/OpenBSD/ or https://ftp.fsn.hu/pub/OpenBSD/ instead? They're fairly nearby.
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
On 2020-02-09, aisha wrote: > You need to use pkill -9 to kill rspamd, which i think should be added > to the stop part of the rspamd daemon. > > At least this is what I have been using, any other methods would be nice > to know. Something wedges in rspamd in the version in 6.6 when you signal it to shutdown, I didn't manage to track it down before 6.6 release. It was fixed in newer rspamd so works just fine in -current, but that's too big of an update to backport to 6.6-stable (and really the main practical effect on 6.6 is that your reboots are ~30 seconds slower than they should be).
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
On 2020-02-09 11:46, aisha wrote: You need to use pkill -9 to kill rspamd, which i think should be added to the stop part of the rspamd daemon. At least this is what I have been using, any other methods would be nice to know. You dont need to restart rspamd if you're just modifying a config file. You can just run "rcctl reload rspamd" to reload your config files if you've made any changes. The rspamd maintainer has acknowledged the issue, and the restarting issue is fixed in current.
IPsec and MTU / fragmentation
Hi misc@,
I've set up an IPsec tunnel to for serving my website from my home. The
tunnel works quite well most of the time, but if I try to deliver big
files over it, the HTTP client never gets a response. After some
testing, if I ran in the HTTP server end
perl -e 'print "a" x 1386;' | doas nc -l 10.200.0.80 80
client receives 1386 "a"s, but with any bigger size the client sees no
response at all.
This smells of MTU / fragmentation issues, but I don't know enough about
networks to configure it properly. Is this the case? Any recommendations
on how to configure a sensible value? Any clue sticks? I can bang
different MTUs until it works, but that solution doesn't seem to scale.
You can find my iked and pf configs below.
Also would like to understand why it happens, so pointers to docs are
more than welcome.
Thanks in advance,
-Lucas
Initiator /etc/iked.conf:
initiator_www = 10.200.0.80
initiator_peer =192.0.2.1
responder = 198.51.100.1
ikev2 "www" active proto tcp \
from $initiator_www port 80 to $responder \
peer $responder \
srcid initiator dstid responder \
tag IPSECWWW
Initiator /etc/pf.conf:
set block-policy drop
set loginterface egress
set skip on lo0
block all
pass out quick on { egress enc0 }
pass in quick on enc0 tagged IPSECWWW
pass in on egress proto tcp to port ssh
pass in on egress inet proto icmp all
pass in on egress inet6 proto ipv6-icmp all
Responder /etc/iked.conf:
initiator_www = 10.200.0.80
initiator_peer =192.0.2.1
responder = 198.51.100.1
ikev2 "www" passive proto tcp \
from $responder to $initiator_www port 80 \
peer $initiator_peer \
srcid responder dstid initiator \
tag IPSECWWW
Responder /etc/pf.conf:
set block-policy drop
set loginterface egress
set skip on lo0
block log all
pass out quick on egress
pass in log on egress proto udp from any to (egress) \
port { isakmp ipsec-nat-t }
pass in log on egress proto esp from any to (egress)
pass in log on enc0 tagged IPSECWWW
pass out log on enc0
pass in on egress proto tcp to port { ssh http https }
pass in on egress inet proto icmp all
pass in on egress inet6 proto icmp6 all
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
You need to use pkill -9 to kill rspamd, which i think should be added to the stop part of the rspamd daemon. At least this is what I have been using, any other methods would be nice to know. --- Aisha blog.aisha.cc On 2020-02-09 14:38, Özgür Kazancci wrote: Hi Stephan, I got the same trouble. Fresh installation of OpenBSD 6.6 and redis+rspamd. Was google-ing regarding that issue and got your workaround. What you mean by "if you enable rspamd etc on boot by rcctl.."? Mine, is already enabled (I issued rcctl enable rspamd after the installation) Thank you, Ozgur. On 29/10/2019 23:44, List wrote: Hi, I am myself running a MX that uses rspamd + postfix. I did have the same issue. Especially when running rspamd and adding redis to the setup. I think what causes the problem is rspamd which uses JITs. These JITS break W^X. If you enable rspamd etc on boot by (rcctl enable ...). And reboot.. Everything works fine. At least for me did. Don't hesitate asking. Kind regards, Stephan
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
Hi Stephan, I got the same trouble. Fresh installation of OpenBSD 6.6 and redis+rspamd. Was google-ing regarding that issue and got your workaround. What you mean by "if you enable rspamd etc on boot by rcctl.."? Mine, is already enabled (I issued rcctl enable rspamd after the installation) Thank you, Ozgur. On 29/10/2019 23:44, List wrote: Hi, I am myself running a MX that uses rspamd + postfix. I did have the same issue. Especially when running rspamd and adding redis to the setup. I think what causes the problem is rspamd which uses JITs. These JITS break W^X. If you enable rspamd etc on boot by (rcctl enable ...). And reboot.. Everything works fine. At least for me did. Don't hesitate asking. Kind regards, Stephan
Re: Dell Latitude e6400 OpenBSD Drive Issue
Hello Michael, > However if my laptop is powered off for a while, the SATA setting > changes back to IRRTL instead of AHCI, very annoying, not sure why > the BIOS would not make my changes persistent. I think it may be a > hardware issue, but just wanted to know if anyone else has > encountered this before? try to replace your BIOS battery with a fresh one. Given the age of your machine, this could be the culprit. -- greetings, Florian Viehweger
Re: Dell Latitude e6400 OpenBSD Drive Issue
On Sun, Feb 09, 2020 at 07:58:25AM -0500, Michael G Workman wrote: > Hello, > > Shout out to the OpenBSD developers for making a great OS! > > I was able to install OpenBSD 6.6 on a Dell Latitude e6400 laptop, with a > USB Install. Sent the dmesg in already. > > The installer would not recognize the hard drive, a brand new SSD drive. > The solution to that, from stack exchange, was to change the SATA settings > in BIOS from IRRTL to AHCI, that fixed the problem. > > However if my laptop is powered off for a while, the SATA setting changes > back to IRRTL instead of AHCI, very annoying, not sure why the BIOS would > not make my changes persistent. I think it may be a hardware issue, but > just wanted to know if anyone else has encountered this before? > > Thanks. > > *Michael G. Workman* > (321) 432-9295 > michael.g.work...@gmail.com This sounds like a BIOS backup battery being flat. -Otto
Dell Latitude e6400 OpenBSD Drive Issue
Hello, Shout out to the OpenBSD developers for making a great OS! I was able to install OpenBSD 6.6 on a Dell Latitude e6400 laptop, with a USB Install. Sent the dmesg in already. The installer would not recognize the hard drive, a brand new SSD drive. The solution to that, from stack exchange, was to change the SATA settings in BIOS from IRRTL to AHCI, that fixed the problem. However if my laptop is powered off for a while, the SATA setting changes back to IRRTL instead of AHCI, very annoying, not sure why the BIOS would not make my changes persistent. I think it may be a hardware issue, but just wanted to know if anyone else has encountered this before? Thanks. *Michael G. Workman* (321) 432-9295 michael.g.work...@gmail.com
Re: How to hide my server's IP?
On Mon, 2020-02-03 at 13:23 +0100, Janne Johansson wrote: > And refine the risk strategies, since the above conversation seem to be > centered around the concept of a hacker that > > 1. Someone successfully attacks your site over the internet, using your > outward facing IP A.A.A.A > 2. Manages to run code on your webserver That outward facing address A.A.A.A seems to be hidden behind a tor web, which means the attacker can access a server without knowing its real IP address. Knowledge of this real IP address may be the ultimate aim of the hack. > 3. May or may not divinate your internal IP B.B.B.B from that code. If that address B.B.B.B is an internal IP address, the hacker may not be able to succeed in the original quest. Note, that the hacker may also find the MAC address of the device, and all connected devices, which may give away the owner of the device. > 4. The communicates information back to a server of their choice, perhaps > using a third (external) ip C.C.C.C or not This appears to be the crucial part. If the hacker can initiate connections from the hacked device, the public facing IP address is prone to discovery. Therefore I propose the following solution: 1. Put the potentially vulnerable device behind a firewall. The firewall forwards requests to the device and back, but allows no outgoing connections from the protected device to the firewall or beyond. 2. Lock down the vulnerable device. If the device does not allow changing its MAC address, patch the kernel to report something else. Also make sure, that your vulnerable device creates no logs. Make sure, that the user account running the potentially vulnerable application can not write to any directory, from which executables can be started or dynamic libraries can be linked against. 3. Barriers are only effective, if they are properly defended. Your firewall must monitor and reliably unusual network activity from the vulnerable host, and shut down all network connections, if suspicious stuff happens. Consider a configuration, in which all disk access goes to a RAM disk, such that a simple reboot restores normal operation. 4. Obviously, no other device must be in the same network, especially not devices, which could provide hints about your identity.
Re: inteldrm switches automatically to full brightness (100%)
On Sun, Feb 09, 2020 at 01:38:05AM +0100, volker wrote:
> Hi,
>
> I have an older HP Elitebook 840 G1. It is a system with FN key to change
> brightness: FN-F9 down, and FN-F10 up.
> btw: both keys don't work... (I was running an OpenSuSE 15 before, they
> worked to change brightness).
> So I installed OpenBSD ("current" for other reasons), and reduced the
> brightness at the restart of the machine, when it still displays the BIOS
> message or the OpenBSD boot prompt.
> The kernel would start normally, and display the blue messages. When the
> inteldrm driver loads, the screens gets shortly dark, and then comes back
> with the 4 blue lines of the inteldrm at the top, but now in full
> brightness.
> Everything else remains in full brightness, I start X automatically, and
> when logged in, I can't change the brightness anymore. Neither with the
> keys, nor with wsconsctl. It stays at 100%.
> I can use wsconsctl on the command line, it responds with a change, but
> actually brightness remains "full" (100%) - no changes:
>
> $ doas wsconsctl display.brightness=50
> display.brightness -> 50.00%
> $ doas wsconsctl display.brightness=10
> display.brightness -> 10.00%
>
> $ xbacklight
> 10.00
> $ doas wsconsctl display.brightness=50
> display.brightness -> 50.00%
> $ xbacklight
> 50.00
Your email triggered me to look into this because I have a somewhat
comparable laptop on my desk (dmesg below) and it suffers from the same
problem. In the archives, I found a couple of things that could help:
1. Disable acpivideo(4) and/or acpivout(4) using UKC [1] [2].
2. Use jcs' intel_backlight_fbsd [3], see
https://github.com/jcs/intel_backlight_fbsd
Both approaches allow me to control the brightness of the screen. FWIW,
output of Linux running on this machine:
$ ls /sys/class/backlight/
intel_backlight
Best regards,
Caspar Schutijser
[1] https://marc.info/?l=openbsd-bugs=152699304722212=2
[2] https://marc.info/?l=openbsd-bugs=142787936328279=2
[3] https://marc.info/?l=openbsd-bugs=149583867702445=2
--
OpenBSD 6.6-current (GENERIC.MP) #628: Sat Feb 1 23:32:22 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17036840960 (16247MB)
avail mem = 16508026880 (15743MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xa9764000 (34 entries)
bios0: vendor HP version "P96 Ver. 01.27" date 04/18/2019
bios0: HP HP EliteBook 1040 G4
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT RTMA UEFI SSDT MSDM SLIC WSMT HPET APIC MCFG SSDT
SSDT SSDT SSDT SSDT SSDT SSDT SSDT DBGP DBG2 DMAR NHLT SSDT ASF! FPDT BGRT SSDT
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4)
TXHC(S3) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S0)
PXSX(S0) RP06(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-7500U CPU @ 2.70GHz, 2595.15 MHz, 06-8e-09
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,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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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 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-7500U CPU @ 2.70GHz, 2593.97 MHz, 06-8e-09
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,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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus 108 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus -1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiprt9 at acpi0: bus 109 (RP09)
acpiprt10 at acpi0: bus -1
Re: inteldrm switches automatically to full brightness (100%)
setting to 0 reduces actualy to minimum.
doas wsconsctl display.brightness=0
display.brightness -> 0.00%
$ xbacklight
0.00
When I then try to "increase" a bit, it switches back to 100% brightness...
$ doas wsconsctl display.brightness=10
display.brightness -> 10.00%
$ xbacklight
10.00
$ doas wsconsctl display.brightness=50
display.brightness -> 50.00%
$ xbacklight
50.00
On 2020-02-09 10:05, Caspar Schutijser wrote:
On Sun, Feb 09, 2020 at 01:38:05AM +0100, volker wrote:
Hi,
I have an older HP Elitebook 840 G1. It is a system with FN key to change
brightness: FN-F9 down, and FN-F10 up.
btw: both keys don't work... (I was running an OpenSuSE 15 before, they
worked to change brightness).
So I installed OpenBSD ("current" for other reasons), and reduced the
brightness at the restart of the machine, when it still displays the BIOS
message or the OpenBSD boot prompt.
The kernel would start normally, and display the blue messages. When the
inteldrm driver loads, the screens gets shortly dark, and then comes back
with the 4 blue lines of the inteldrm at the top, but now in full
brightness.
Everything else remains in full brightness, I start X automatically, and
when logged in, I can't change the brightness anymore. Neither with the
keys, nor with wsconsctl. It stays at 100%.
I can use wsconsctl on the command line, it responds with a change, but
actually brightness remains "full" (100%) - no changes:
$ doas wsconsctl display.brightness=50
display.brightness -> 50.00%
$ doas wsconsctl display.brightness=10
display.brightness -> 10.00%
$ xbacklight
10.00
$ doas wsconsctl display.brightness=50
display.brightness -> 50.00%
$ xbacklight
50.00
What happens when you set the brightness to 0? i.e.
$ doas wsconsctl display.brightness=0
Re: inteldrm switches automatically to full brightness (100%)
On Sun, Feb 09, 2020 at 01:38:05AM +0100, volker wrote:
> Hi,
>
> I have an older HP Elitebook 840 G1. It is a system with FN key to change
> brightness: FN-F9 down, and FN-F10 up.
> btw: both keys don't work... (I was running an OpenSuSE 15 before, they
> worked to change brightness).
> So I installed OpenBSD ("current" for other reasons), and reduced the
> brightness at the restart of the machine, when it still displays the BIOS
> message or the OpenBSD boot prompt.
> The kernel would start normally, and display the blue messages. When the
> inteldrm driver loads, the screens gets shortly dark, and then comes back
> with the 4 blue lines of the inteldrm at the top, but now in full
> brightness.
> Everything else remains in full brightness, I start X automatically, and
> when logged in, I can't change the brightness anymore. Neither with the
> keys, nor with wsconsctl. It stays at 100%.
> I can use wsconsctl on the command line, it responds with a change, but
> actually brightness remains "full" (100%) - no changes:
>
> $ doas wsconsctl display.brightness=50
> display.brightness -> 50.00%
> $ doas wsconsctl display.brightness=10
> display.brightness -> 10.00%
>
> $ xbacklight
> 10.00
> $ doas wsconsctl display.brightness=50
> display.brightness -> 50.00%
> $ xbacklight
> 50.00
What happens when you set the brightness to 0? i.e.
$ doas wsconsctl display.brightness=0
