Re: dmesg for Riverbed Steelhead 250/550
Here's a quick rundown on how I got it installed - you will need an existing OpenBSD installation. 1. Download the FS install image. 2. Mount it in your existing OpenBSD system and edit etc/boot.conf to set the tty to com0. 3. Write the resulting image to a USB stick. 4. Plug in your USB stick, then plug in the power. 5. When it says to press any key, do so. When the GRUB menu appears, hit 'c'. 6. Set the root device (which will likely be hd2): root (hd2) 7. Fire up the chainloader: chainloader +1 8. Boot: boot 9. ??? 10. Profit! On Tue, Nov 19, 2019 at 1:31 PM Aaron Mason wrote: > > All > > Fired up OpenBSD 6.6 on a Riverbed Steelhead 250 and a 550, purchased > from fleabay for about $30 ea (plus shipping) - the 250 runs a single > core Celeron M @ 1.66GHz and 1GB DDR2, the 550 runs a low power > dual-core Xeon at the same speed and 2GB DDR2 - both x86 only. Both > have a 2GB USB DOM and a separate laptop HDD (120GB for the 250 and > 320GB for the 550) likely for caching (these being WAN accelerators). > > The primary and AUX NICs work, the LAN0/0 and WAN0/0 ports do not, > likely because there's some GPIO magic required to switch back the > relays. The Xeon-powered 550 definitely seems to have a bit more > oompf than the 250's hamster whee-- err, Celeron M CPU. > > The output for dmesg for each is attached. > > -- > Aaron Mason - Programmer, open source addict > I've taken my software vows - for beta or for worse -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
dmesg for Riverbed Steelhead 250/550
All
Fired up OpenBSD 6.6 on a Riverbed Steelhead 250 and a 550, purchased
from fleabay for about $30 ea (plus shipping) - the 250 runs a single
core Celeron M @ 1.66GHz and 1GB DDR2, the 550 runs a low power
dual-core Xeon at the same speed and 2GB DDR2 - both x86 only. Both
have a 2GB USB DOM and a separate laptop HDD (120GB for the 250 and
320GB for the 550) likely for caching (these being WAN accelerators).
The primary and AUX NICs work, the LAN0/0 and WAN0/0 ports do not,
likely because there's some GPIO magic required to switch back the
relays. The Xeon-powered 550 definitely seems to have a bit more
oompf than the 250's hamster whee-- err, Celeron M CPU.
The output for dmesg for each is attached.
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
OpenBSD 6.6 (GENERIC) #298: Sat Oct 12 11:06:10 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 1073037312 (1023MB)
avail mem = 1037803520 (989MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 10/22/13, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @
0x9f800 (40 entries)
bios0: vendor American Megatrends Inc. version "MINOW035" date 10/22/2013
bios0: Riverbed Technology, Inc. DTABA
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET
acpi0: wakeup devices P0P1(S4) SLPB(S4)
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) M CPU @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz,
06-0e-0c
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,SSE3,MWAIT,TM2,xTPR,PDCM,NXE,PERF,SENSOR,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2, IBE
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 7 (EPA0)
acpiprt2 at acpi0: bus 6 (EPA1)
acpiprt3 at acpi0: bus 5 (P0P4)
acpiprt4 at acpi0: bus 4 (P0P5)
acpiprt5 at acpi0: bus 3 (P0P6)
acpicpu0 at acpi0: C1(@1 halt!)
acpitz0 at acpi0: critical temperature is 99 degC
acpipwrres0 at acpi0: GFAN, resource for SBRG, FN00
"PNP0A08" at acpi0 not configured
acpicmos0 at acpi0
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
"PNP0C0B" at acpi0 not configured
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 3100 Host" rev 0x00
"Intel 3100 Error Reporting" rev 0x00 at pci0 dev 0 function 1 not configured
vendor "Intel", unknown product 0x35b5 (class system subclass miscellaneous,
rev 0x00) at pci0 dev 1 function 0 not configured
ppb0 at pci0 dev 2 function 0 "Intel 3100 EDMA" rev 0x00
pci1 at ppb0 bus 7
ppb1 at pci0 dev 3 function 0 "Intel 3100 PCIE" rev 0x00
pci2 at ppb1 bus 6
em0 at pci2 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 1 int 16, address
00:0e:b6:95:dc:0e
em1 at pci2 dev 0 function 1 "Intel 82571EB" rev 0x06: apic 1 int 17, address
00:0e:b6:95:dc:0f
ppb2 at pci0 dev 28 function 0 "Intel 6321ESB PCIE" rev 0x01
pci3 at ppb2 bus 5
em2 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:0e:b6:3e:23:08
ppb3 at pci0 dev 28 function 1 "Intel 6321ESB PCIE" rev 0x01
pci4 at ppb3 bus 4
em3 at pci4 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:0e:b6:3e:23:09
ppb4 at pci0 dev 28 function 2 "Intel 6321ESB PCIE" rev 0x01: apic 1 int 18
pci5 at ppb4 bus 3
ppb5 at pci0 dev 28 function 3 "Intel 6321ESB PCIE" rev 0x01
pci6 at ppb5 bus 2
uhci0 at pci0 dev 29 function 0 "Intel 6321ESB USB" rev 0x01: apic 1 int 23
uhci1 at pci0 dev 29 function 1 "Intel 6321ESB USB" rev 0x01: apic 1 int 19
ehci0 at pci0 dev 29 function 7 "Intel 6321ESB USB" rev 0x01: apic 1 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
ppb6 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xc9
pci7 at ppb6 bus 1
ichpcib0 at pci0 dev 31 function 0 "Intel 6321ESB LPC" rev 0x01: PM disabled
ahci0 at pci0 dev 31 function 2 "Intel 6321ESB AHCI" rev 0x01: apic 1 int 19,
AHCI 1.1
ahci0: port 0: 1.5Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: naa.50e0448be8ca
sd0: 114473MB, 512 bytes/sector, 234441648 sectors
ichiic0 at pci0 dev 31 function 3 "Intel 6321ESB SMBus" rev 0x01: apic 1 int 19
iic0 at ichiic0
ichiic0: abort failed, status 0x41
iic0: addr 0x24 a1=ff a2=ff a3=ff a4=ff a5=ff a6=ff a7=ff e1=02 e3=02 words
00=01aa 01=01aa 02=01aa 03=01aa 04=01aa 05=01aa 06=01aa 07=01aa
adt0 at iic0 addr 0x2e: sch5017 rev 0x8a
iic0: addr 0x48 00=22 02=4b 03=50 04=22 06=4b 07=50 08=22 0a=4b 0b=50 0c=22
0e=4b 0f=50 10=22 12=4b 13=50 14=22 16=4b 17=50 18=22 1a=4b 1b=50 1c=22 1e=4b
1f=50 20=22 22=4b 23=50
Re: Iked/unbound ~ more info.
I don't know how unbound will be aware of iked couple/decouple, so I wonder how I'd specify "as appropriate" in this case short of a DNS failover from the remote side using forward-zones in unbound. I'll take a look at unwind... On 11/18/19, Dale C. wrote: > "I'd go for a local unbound or local unwind instance, listening for > queries on localhost, configured to use a forwarder as appropriate, plus > the bypass rule suggested in faq17." > > Right. > > Thanks again, > > Dale > > On 11/18/19, Dale C. wrote: >> Stuart, >> >> Hmmm, thanks for taking the time to write. I'll consider these things. >> >> My server has a static IP, and I'd also like to start looking at DNS >> over TLS. My client has a dynamic (shared even - cellular gateway) IP >> address. >> >> There are some implications there I'll also need to consider. Routing >> DNS through to the server which can do DoT would be difficult without >> accepting DNS config from the responder, no? >> >> Thank you, >> >> Dale >> >
Re: Iked/unbound ~ more info.
"I'd go for a local unbound or local unwind instance, listening for queries on localhost, configured to use a forwarder as appropriate, plus the bypass rule suggested in faq17." Right. Thanks again, Dale On 11/18/19, Dale C. wrote: > Stuart, > > Hmmm, thanks for taking the time to write. I'll consider these things. > > My server has a static IP, and I'd also like to start looking at DNS > over TLS. My client has a dynamic (shared even - cellular gateway) IP > address. > > There are some implications there I'll also need to consider. Routing > DNS through to the server which can do DoT would be difficult without > accepting DNS config from the responder, no? > > Thank you, > > Dale >
Re: Iked/unbound ~ more info.
Hi Dale, I had unbound working with iked for a short time. I actually configured the interface enc0 like so; ** Server hostname.enc0 inet 10.0.5.1 255.255.255.0 10.0.5.255 --- ** Server iked.conf ikev2 “roaming" passive esp \ from 0.0.0.0/0 to 0.0.0.0/0 \ local egress peer any \ psk "---" \ config protected-subnet 0.0.0.0/0 \ config address 10.0.5.0/24 \ config name-server 10.0.5.1 \ tag "IKED" As you can see I then added the IP of the enc0 interface in iked.conf "config name-server 10.0.5.1”. I then added the subnet 10.0.5.0/24 as an “allow “ in the unbound.conf access-control: 10.0.5.0/24 allow Though I too am not sure if this is a good way of using iked and unbound. In fact I actually stopped using this and just added a Public DNS server like 1.1.1.1. >From all my reading, I think it is not required to configure the enc0 >interface. Further testing using an OpenBSD iked client, I had very little success is making that work. For my scenario I have iPhones and MacBooks using the native ikev2 Apple client and they work fine. All the clients get the Public IP of the iked Server when they connect. Nino > On 19 Nov 2019, at 7:46 am, Dale C. wrote: > > I'm thinking you're correct Chuck, I can't route traffic for localhost > through iked... > > So... "It might be necessary to exclude this traffic from the > flows to ensure connections to services running locally (such as a > local resolver) > > ^ Then I'd have local dns while connected to my VPN? > > OH... queries to external nameservers will still go through the VPN > though? So it should be alright? > > I'd much rather be doing DNS on the responder localhost though... > isn't that the correct way here? > > So, I'll try that, but any better solution for openbsd -> openbsd iked > when both are using unbound localhost DNS would be appreciated :) > > It works. > > Thanks Chuck ;) > > On 11/18/19, Dale C. mailto:maatk...@gmail.com>> wrote: >> Chuck, >> >> Hey thanks for the information. Yeah I've tried having unbound listen >> on 10.0.1.2 (the VPN support net), that didn't work. I have not tried >> putting unbound on an external interface, and would like to avoid >> that. >> >> I've actually taken unbound out of the equation on both sides. >> Disabled unbound, commented supercede directive from dhclient and used >> public name servers on both ends - that didn't work. >> >> Today, I'll try some things again with the simplified pf confs. I'll >> get some output from pflog. I'll try putting unbound on the public IP. >> >> In the faq there are a few lines: >> >> "Since all traffic goes through the VPN, including traffic targeted at >> localhost, it might be necessary to exclude this traffic from the >> flows to ensure connections to services running locally (such as a >> local resolver) reach the right target. This can be achieved by adding >> a single line to /etc/ipsec.conf on the initiator: flow from >> 127.0.0.1/32 to 127.0.0.1/32 type bypass" >> >> ^ I'm confused by this, i excluded this ipsec bypass and the rdr-to >> rule in the responder pf conf. I would've expected that to work with >> DNS targeting localhost? I'm also not clear how `match out log on enc0 >> inet all nat-to 10.0.5.2' behaves, is it akin to a "quick" directive? >> Packets do not evaluate further rules because there are no more inet >> packets after this? Does the position of this line in my initiator >> pf.conf seem reasonable? I think perhaps it should go up... >> >> Also this: "One caveat with using an OpenBSD client is that it doesn't >> send configuration requests to the responder to configure its IP, so >> the initiator needs to manually NAT its outgoing packets on the enc0 >> interface so that packets appear on the responder with an IP on the >> VPN subnet." >> >> I tried a config name-server directive on the initiator iked.conf, but >> because it wants to verify the host at load-time, I get iked start >> errors with it. *I think this is the reason anyway, I'll take a closer >> look today*... So, I'm kind of wondering if a seamless way to switch >> in and out of the VPN exists for openbsd clients? I should be able to >> `ikectl couple/decouple' and just have it work right, so I'm looking >> for a way to configure name-server in the iked.conf initiator ideally? >> >> I'll go through your post a few more times and try your suggestions, >> thank you very much! >> >> Dale >> >>> Chuck Wrote >>> I am not sure if you noticed but 127.0.0.1 is always local to the machine >>> using it. If you try routing with it the packets will never leave the >>> system. If they do somehow leave then the system getting them will >>> reject >>> it as the packet did not come from itself. I mention this as I see in >>> both resolve.conf files the nameserver is listed as 127.0.0.1 >>> >>> You might try instead to have the unbound listen on the inside (or even >>> the outside) address.
Re: Iked/unbound ~ more info.
Stuart, Hmmm, thanks for taking the time to write. I'll consider these things. My server has a static IP, and I'd also like to start looking at DNS over TLS. My client has a dynamic (shared even - cellular gateway) IP address. There are some implications there I'll also need to consider. Routing DNS through to the server which can do DoT would be difficult without accepting DNS config from the responder, no? Thank you, Dale
Re: Iked/unbound ~ more info.
On 2019-11-18, Dale C. wrote: > "Since all traffic goes through the VPN, including traffic targeted at > localhost, it might be necessary to exclude this traffic from the > flows to ensure connections to services running locally (such as a > local resolver) reach the right target. This can be achieved by adding > a single line to /etc/ipsec.conf on the initiator: flow from > 127.0.0.1/32 to 127.0.0.1/32 type bypass" > > ^ I'm confused by this, i excluded this ipsec bypass and the rdr-to > rule in the responder pf conf. On OpenBSD (and many other systems) IPsec works with "flows" which, for want of a better word, "steal" traffic so that it doesn't follow the routing table but instead matching traffic is diverted over the VPN. (This is the traditional way of handling IPsec; some systems also do "route based" IPsec which is a bit more straightforward for people who understand IP routing but that's not possible with OpenBSD without an additional tunnel interface). > I would've expected that to work with > DNS targeting localhost? I'm also not clear how `match out log on enc0 > inet all nat-to 10.0.5.2' behaves, is it akin to a "quick" directive? > Packets do not evaluate further rules because there are no more inet > packets after this? Does the position of this line in my initiator > pf.conf seem reasonable? I think perhaps it should go up... NAT rules take place *after* traffic has been selected by flows. (This is why there's a special "srcnat" config in iked.conf/ipsec.conf to handle this). For this simple case with 0.0.0.0/0 I don't think you'll need to touch that, just the "flow from 127.0.0.1/32 to 127.0.0.1/32 type bypass" in ipsec.conf should do the trick. (Yes, ipsec.conf, even though you're using iked! iked doesn't have a way to handle setting up bypass flows itself other than the built-in very annoying "block IPv6 by default" mode that is enabled by default, so you need to defer to ipsec.conf + ipsecctl for this). > I tried a config name-server directive on the initiator iked.conf, but "config name-server" is something that would go on the responder side, but it's pointless if the only clients are iked. > I should be able to > `ikectl couple/decouple' and just have it work right, so I'm looking > for a way to configure name-server in the iked.conf initiator ideally? I'd go for a local unbound or local unwind instance, listening for queries on localhost, configured to use a forwarder as appropriate, plus the bypass rule suggested in faq17.
Re: Tape drive
Hi, Thanks for the answer, yes it is indeed second hand - even though they guaranteed what it is working. I've updated and I am still getting the same result, I will try cleaning it first... and fingers crossed. Thanks, P. On Mon, Nov 18, 2019 at 2:02 PM Kenneth Gober wrote: > > On Sun, Nov 17, 2019 at 6:00 PM Pietro Paolini > wrote: >> >> On a x86-64 Dell, the tape drive is an HP StorageWorks Ultrium 960. >> >> # tar cf /dev/rst0 ./test.txt >> # mt -f /dev/nrst0 rewind >> # tar xf /dev/rst0 .out >> tar: Failed read on archive volume 1: Input/output error >> tar: Unable to recover from an archive read failure. >> tar: Sorry, unable to determine archive format. >> >> What can I do to diagnose the problem ? Using other utilities such as >> pax did not make any difference. > > > That model is an LTO3 tape drive, which at this point is very old. Did you > purchase > it used, by chance? It's possible that the hardware is simply defective. > I've bought > several used tape drives and while most of them worked fine, some did not. I > think > I had one that didn't work until I ran a cycle with a cleaning cartridge. > > It's also possible that your tapes are defective. I've bought tapes on eBay > where it > turned out that 2 out of 3 tapes in the box were bad. > > I use LTO2/4 drives routinely with dump/restore, and very occasionally with > tar, and > there is nothing special you have to do to make it work. SCSI and SAS drives > work > equally well (I have both). The only thing special about LTO is that you > have to match > the tape and drive. An LTO3 tape drive will read LTO1, LTO2 and LTO3 tapes, > but it > will not write LTO1 (only 2 and 3). > > So your diagnostic steps should include: > 1. run a cleaning cartridge cycle > 2. try a different tape (from a different batch or manufacturer) > 3. try another drive > > -ken
Re: 'machine/cdefs.h' file not found when installing nokogiri gem
On 2019-11-16, mabi wrote: > ‐‐‐ Original Message ‐‐‐ > On Saturday, November 16, 2019 2:38 PM, Stuart Henderson > wrote: > >> For native extensions, it's really best to install from packages. >> >> pkg_add ruby25-nokogiri > > Thanks for the tip, I didn't think about that alternative. What puzzles me is > that I managed to install that nokogiri gem on OpenBSD 6.4 using 'gem > install' in the past. Will have to check with 6.6. > > For the actual problem: I suspect you may have done an install at some point without the comp*.tgz set and so didn't get the machine -> amd64 symlink correctly installed in /usr/include. Fix for this would be to rm -r /usr/include/* then boot the "bsd.rd" install kernel and tell it to do an upgrade to the version you're currently using, and install all sets, then re-run syspatch when you've rebooted. But using packages means that you'll automatically get updates from pkg_add -u when you update the OS, as these may be needed to cope with updates to Ruby/libc/kernel versions. So that's why I'd suggest them.
Re: Iked/unbound ~ more info.
I'm thinking you're correct Chuck, I can't route traffic for localhost through iked... So... "It might be necessary to exclude this traffic from the flows to ensure connections to services running locally (such as a local resolver) ^ Then I'd have local dns while connected to my VPN? OH... queries to external nameservers will still go through the VPN though? So it should be alright? I'd much rather be doing DNS on the responder localhost though... isn't that the correct way here? So, I'll try that, but any better solution for openbsd -> openbsd iked when both are using unbound localhost DNS would be appreciated :) It works. Thanks Chuck ;) On 11/18/19, Dale C. wrote: > Chuck, > > Hey thanks for the information. Yeah I've tried having unbound listen > on 10.0.1.2 (the VPN support net), that didn't work. I have not tried > putting unbound on an external interface, and would like to avoid > that. > > I've actually taken unbound out of the equation on both sides. > Disabled unbound, commented supercede directive from dhclient and used > public name servers on both ends - that didn't work. > > Today, I'll try some things again with the simplified pf confs. I'll > get some output from pflog. I'll try putting unbound on the public IP. > > In the faq there are a few lines: > > "Since all traffic goes through the VPN, including traffic targeted at > localhost, it might be necessary to exclude this traffic from the > flows to ensure connections to services running locally (such as a > local resolver) reach the right target. This can be achieved by adding > a single line to /etc/ipsec.conf on the initiator: flow from > 127.0.0.1/32 to 127.0.0.1/32 type bypass" > > ^ I'm confused by this, i excluded this ipsec bypass and the rdr-to > rule in the responder pf conf. I would've expected that to work with > DNS targeting localhost? I'm also not clear how `match out log on enc0 > inet all nat-to 10.0.5.2' behaves, is it akin to a "quick" directive? > Packets do not evaluate further rules because there are no more inet > packets after this? Does the position of this line in my initiator > pf.conf seem reasonable? I think perhaps it should go up... > > Also this: "One caveat with using an OpenBSD client is that it doesn't > send configuration requests to the responder to configure its IP, so > the initiator needs to manually NAT its outgoing packets on the enc0 > interface so that packets appear on the responder with an IP on the > VPN subnet." > > I tried a config name-server directive on the initiator iked.conf, but > because it wants to verify the host at load-time, I get iked start > errors with it. *I think this is the reason anyway, I'll take a closer > look today*... So, I'm kind of wondering if a seamless way to switch > in and out of the VPN exists for openbsd clients? I should be able to > `ikectl couple/decouple' and just have it work right, so I'm looking > for a way to configure name-server in the iked.conf initiator ideally? > > I'll go through your post a few more times and try your suggestions, > thank you very much! > > Dale > >> Chuck Wrote >> I am not sure if you noticed but 127.0.0.1 is always local to the machine >> using it. If you try routing with it the packets will never leave the >> system. If they do somehow leave then the system getting them will >> reject >> it as the packet did not come from itself. I mention this as I see in >> both resolve.conf files the nameserver is listed as 127.0.0.1 >> >> You might try instead to have the unbound listen on the inside (or even >> the outside) address. After that only allow access to it from the IKE >> networks. >> >> I would also mention that rdr-to is not NAT. It does reroute the packets >> but the return packets can take a different route. If the unbound is >> listening on 127.0.0.1 then that is where the packets will be coming >> from. >> You would need to NAT the outgoing DNS packets to the correct interface. >> >> No idea if any of this will help you. >> >> >> I did see a request on pflog, here is a really brief run down on how it >> is >> used. >> >> 1. Add 'log' to one of the rules. Ex rule from your pf rules: >> #name servers >> pass out log on $ext proto udp from $ext to any port $udp_services >> >> 2. View the pflog after some of the packets have been captured. Ex: >> /usr/sbin/tcpdump -n -e -ttt -s1500 -r /var/log/pflog >> >> This will display the packets in tcpdump format. The -e option is to >> give >> you the rule number that captured the packet, in case you have multiple >> logging rules. You can get the rule number from your pf.conf file by >> doing: /usr/sbin/pf -nvvvf /etc/pf.conf >> >> The -n is so the rules do not reload. The rule is @# >> >> >> Have Fun! >> Chuck Hall >> >> >>> Update: >>> >>> Spent a lot of time trying different things, still no DNS. >>> >>> Simplified and cleaned up all my confs as much as possible. >>> >>> Everything works, but DNS. >>> >>>
ahci cd/dvd failure key_sense
On amd64 6.6release/stable and -current my TSSTcorp CDDVDW SH-223DB has failed to function. It does not key_sense and backends cdio/xorriso-tcltk seem to write a lead-in track and nothing else. The system dual boots with Debian 10 the same drive is recognized and works without issue. # xorriso -as cdrecord dev=/dev/rcd0c crux-3.5-updated.iso xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev '/dev/rcd0c' Media current: CD-R Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 703m free Beginning to write data track. libburn : FATAL : SCSI error on write(-22,16): See MMC specs: Sense Key 2 "Drive not ready", ASC 00 ASCQ 00. libburn : FATAL : CDB= WRITE(10) : 2a 00 ff ff ff ea 00 00 10 00 : dxfer_len= 32768 libburn : FAILURE : Failed to synchronize drive cache. SCSI error : See MMC specs: Sense Key 2 "Drive not ready", ASC 00 ASCQ 00. xorriso : FATAL : -abort_on 'FAILURE' encountered 'FATAL' during image writing xorriso : NOTE : libburn has now been urged to cancel its operation libburn : FATAL : Burn run failed xorriso : FAILURE : libburn indicates failure with writing. xorriso : NOTE : Gave up -outdev '' xorriso : FAILURE : -as cdrecord: Job could not be performed properly. xorriso : aborting : -abort_on 'FAILURE' encountered 'FATAL' If found this which seems to fit the issue I am having. https://marc.info/?l=openbsd-misc=147411010102451=2 There were no F/U's to this post. It appears this is device dependent. Can anyone recommend a make/model of SATA drive that can be used in OpenBSD. The recommended to use "xorriso -as cdrecord" in OpenBSD? Lastly, are any developer interested in addressing key sense in the ahci driver? I'm willing to test on the hardware I have. -- J. Scott Heppler
Re: Iked/unbound ~ more info.
Chuck,
Hey thanks for the information. Yeah I've tried having unbound listen
on 10.0.1.2 (the VPN support net), that didn't work. I have not tried
putting unbound on an external interface, and would like to avoid
that.
I've actually taken unbound out of the equation on both sides.
Disabled unbound, commented supercede directive from dhclient and used
public name servers on both ends - that didn't work.
Today, I'll try some things again with the simplified pf confs. I'll
get some output from pflog. I'll try putting unbound on the public IP.
In the faq there are a few lines:
"Since all traffic goes through the VPN, including traffic targeted at
localhost, it might be necessary to exclude this traffic from the
flows to ensure connections to services running locally (such as a
local resolver) reach the right target. This can be achieved by adding
a single line to /etc/ipsec.conf on the initiator: flow from
127.0.0.1/32 to 127.0.0.1/32 type bypass"
^ I'm confused by this, i excluded this ipsec bypass and the rdr-to
rule in the responder pf conf. I would've expected that to work with
DNS targeting localhost? I'm also not clear how `match out log on enc0
inet all nat-to 10.0.5.2' behaves, is it akin to a "quick" directive?
Packets do not evaluate further rules because there are no more inet
packets after this? Does the position of this line in my initiator
pf.conf seem reasonable? I think perhaps it should go up...
Also this: "One caveat with using an OpenBSD client is that it doesn't
send configuration requests to the responder to configure its IP, so
the initiator needs to manually NAT its outgoing packets on the enc0
interface so that packets appear on the responder with an IP on the
VPN subnet."
I tried a config name-server directive on the initiator iked.conf, but
because it wants to verify the host at load-time, I get iked start
errors with it. *I think this is the reason anyway, I'll take a closer
look today*... So, I'm kind of wondering if a seamless way to switch
in and out of the VPN exists for openbsd clients? I should be able to
`ikectl couple/decouple' and just have it work right, so I'm looking
for a way to configure name-server in the iked.conf initiator ideally?
I'll go through your post a few more times and try your suggestions,
thank you very much!
Dale
On 11/18/19, ch...@qatland.com wrote:
> I am not sure if you noticed but 127.0.0.1 is always local to the machine
> using it. If you try routing with it the packets will never leave the
> system. If they do somehow leave then the system getting them will reject
> it as the packet did not come from itself. I mention this as I see in
> both resolve.conf files the nameserver is listed as 127.0.0.1
>
> You might try instead to have the unbound listen on the inside (or even
> the outside) address. After that only allow access to it from the IKE
> networks.
>
> I would also mention that rdr-to is not NAT. It does reroute the packets
> but the return packets can take a different route. If the unbound is
> listening on 127.0.0.1 then that is where the packets will be coming from.
> You would need to NAT the outgoing DNS packets to the correct interface.
>
> No idea if any of this will help you.
>
>
> I did see a request on pflog, here is a really brief run down on how it is
> used.
>
> 1. Add 'log' to one of the rules. Ex rule from your pf rules:
> #name servers
> pass out log on $ext proto udp from $ext to any port $udp_services
>
> 2. View the pflog after some of the packets have been captured. Ex:
> /usr/sbin/tcpdump -n -e -ttt -s1500 -r /var/log/pflog
>
> This will display the packets in tcpdump format. The -e option is to give
> you the rule number that captured the packet, in case you have multiple
> logging rules. You can get the rule number from your pf.conf file by
> doing: /usr/sbin/pf -nvvvf /etc/pf.conf
>
> The -n is so the rules do not reload. The rule is @#
>
>
> Have Fun!
> Chuck Hall
>
>
>> Update:
>>
>> Spent a lot of time trying different things, still no DNS.
>>
>> Simplified and cleaned up all my confs as much as possible.
>>
>> Everything works, but DNS.
>>
>> ##initiator pf.conf
>> #declare variables
>> tcp_services = " { ssh, https, http } "
>> udp_services = " { domain } "
>> ext = " iwn0 "
>>
>> #tables
>> table persist { 155.138.139.17 }
>>
>> set skip on lo0
>>
>> block drop
>>
>> #sshserver
>> pass in log on $ext proto tcp from any to port 22 synproxy state
>>
>> #name servers
>> pass out log on $ext proto udp from $ext to any port $udp_services
>>
>> #Serving dns on lan
>> pass in on $ext proto udp from 192.168.0.0/24 to any port $udp_services
>>
>> #State
>> pass out keep state
>>
>> #roadwarrior
>> match out log on enc0 inet all nat-to 10.0.1.2
>>
>> ##initiator iked.conf
>>
>> ikev2 'roadwarrior' active esp \
>> from 0.0.0.0/0 to 0.0.0.0/0 \
>> peer 155.138.139.17 \
>> srcid roadwarrior
Re: Best Practices for growing disk partitions on a server
Stuart Henderson wrote: > On 2019-11-17, Lev Lazinskiy wrote: > > Hi folks, > > > > I am new to openBSD, so forgive me if I am missing something obvious. > > > > I recently installed openBSD on a server using the auto-partition layout > > during installation and am quickly starting to run out of disk space. > > > > I have read the section in the FAQ [1] regarding how to grow a disk > > partition, but I am confused on the best way to actually do this. > > > > Specifically, I am trying to grow /usr and /home but they are "busy" > > when I try to follow these steps on a running server. > > > > Is the assumption that you are supposed to reboot the server with the > > ISO attached and pop into a shell to complete these steps? > > > > [1] https://www.openbsd.org/faq/faq14.html#GrowPartition > > > > This faq entry tells you to use growfs, which won't work for /usr > from a standard auto-defaults install because it requires empty space > immediately following the partition to grow into. > > On a larger disk it often will work for /home because auto-defaults > place it at the end of the disk, size it at max 300G, and leave the space > following it empty. > > Sometimes you can shunt things around - if you have free space at the end > of the disk you can move files from the filesystem immediately following > /usr there, and growfs into the now-vacated space - sometimes you have > another partition that is A) larger than /usr and B) that is larger than > you need, in which case you copy files so you can swap them around. > Or again if you have free space at the end of the disk, after what you'd > want to grow /home into, you can make a new partition there, copy the > files, and leave the former /usr partition empty. But it's quite delicate > work and is often easier to reinstall. > > Interested what you are bumping into on /usr, on a recently installed > system the default size is usually ok for most uses unless it's a small > disk or unless you are building ports and don't have a separate /usr/ports > partition. (If you *are* using ports and have free space at the end - > as above - you could create a new partition to hold /usr/ports in there > and move *those* files across - that's a much easier proposition than > moving the whole of /usr. Which is to say, there are all sorts of complexities, and you'll have to work through them. On the other hand learning how to save all your files, and then do a fresh install, is like gaining a superpower.
Re: Best Practices for growing disk partitions on a server
On 2019-11-17, Lev Lazinskiy wrote: > Hi folks, > > I am new to openBSD, so forgive me if I am missing something obvious. > > I recently installed openBSD on a server using the auto-partition layout > during installation and am quickly starting to run out of disk space. > > I have read the section in the FAQ [1] regarding how to grow a disk > partition, but I am confused on the best way to actually do this. > > Specifically, I am trying to grow /usr and /home but they are "busy" > when I try to follow these steps on a running server. > > Is the assumption that you are supposed to reboot the server with the > ISO attached and pop into a shell to complete these steps? > > [1] https://www.openbsd.org/faq/faq14.html#GrowPartition > This faq entry tells you to use growfs, which won't work for /usr from a standard auto-defaults install because it requires empty space immediately following the partition to grow into. On a larger disk it often will work for /home because auto-defaults place it at the end of the disk, size it at max 300G, and leave the space following it empty. Sometimes you can shunt things around - if you have free space at the end of the disk you can move files from the filesystem immediately following /usr there, and growfs into the now-vacated space - sometimes you have another partition that is A) larger than /usr and B) that is larger than you need, in which case you copy files so you can swap them around. Or again if you have free space at the end of the disk, after what you'd want to grow /home into, you can make a new partition there, copy the files, and leave the former /usr partition empty. But it's quite delicate work and is often easier to reinstall. Interested what you are bumping into on /usr, on a recently installed system the default size is usually ok for most uses unless it's a small disk or unless you are building ports and don't have a separate /usr/ports partition. (If you *are* using ports and have free space at the end - as above - you could create a new partition to hold /usr/ports in there and move *those* files across - that's a much easier proposition than moving the whole of /usr.
Re: Home NAS
What can be newer or not existent yesterday, but has the same filename? Something that one changed with an editor? Would not be better to use a version contro system? Rod. On Mon, 18 Nov 2019, Nick Holland wrote: On 2019-11-17 11:39, Jean-François Simon wrote: Hi, I found it, there exist glastree which is available from ports. Nice small "poor man's" backup as the author qualifies, though makes incremental backup through hard links: # if yesterday does not exist or today is newer, copy the file # else hard link the file to yesterday rsync --link-dest -- it's been in rsync for well over 10 years at this point. Little wrapper shell script and away you go...
Re: Tape drive
On Sun, Nov 17, 2019 at 6:00 PM Pietro Paolini < pietro.paol...@cognitivecredit.com> wrote: > On a x86-64 Dell, the tape drive is an HP StorageWorks Ultrium 960. > > # tar cf /dev/rst0 ./test.txt > # mt -f /dev/nrst0 rewind > # tar xf /dev/rst0 .out > tar: Failed read on archive volume 1: Input/output error > tar: Unable to recover from an archive read failure. > tar: Sorry, unable to determine archive format. > > What can I do to diagnose the problem ? Using other utilities such as > pax did not make any difference. > That model is an LTO3 tape drive, which at this point is very old. Did you purchase it used, by chance? It's possible that the hardware is simply defective. I've bought several used tape drives and while most of them worked fine, some did not. I think I had one that didn't work until I ran a cycle with a cleaning cartridge. It's also possible that your tapes are defective. I've bought tapes on eBay where it turned out that 2 out of 3 tapes in the box were bad. I use LTO2/4 drives routinely with dump/restore, and very occasionally with tar, and there is nothing special you have to do to make it work. SCSI and SAS drives work equally well (I have both). The only thing special about LTO is that you have to match the tape and drive. An LTO3 tape drive will read LTO1, LTO2 and LTO3 tapes, but it will not write LTO1 (only 2 and 3). So your diagnostic steps should include: 1. run a cleaning cartridge cycle 2. try a different tape (from a different batch or manufacturer) 3. try another drive -ken
Re: Home NAS
On 2019-11-17 11:39, Jean-François Simon wrote: > Hi, > > I found it, there exist glastree which is available from ports. > > Nice small "poor man's" backup as the author qualifies, > though makes incremental backup through hard links: > > # if yesterday does not exist or today is newer, copy the file > # else hard link the file to yesterday rsync --link-dest -- it's been in rsync for well over 10 years at this point. Little wrapper shell script and away you go... Nick.
Re: pkg_info -Q bug?
Hello, I just wanted to add to this thread that I incurred in the same issue on a fresh 6.6 installation. I also tried with a different mirror in /etc/installurl and receive the same partial response from pkg_info -Q. What makes it even more odd is that pkg_add finds the correct package. Cheers, Antonio Bibiano On Fri, Nov 08, 2019 at 09:34:06PM GMT, Dumitru Moldovan wrote: >On Fri, Nov 08, 2019 at 08:04:45PM +, Raf Czlonka wrote: >>On Fri, Nov 08, 2019 at 05:45:23PM GMT, Dumitru Moldovan wrote: >>> >>> Hi misc, >>> >>> I see pkg_info's man page says: >>> >>>-Q query >>>Show all packages in $PKG_PATH which match the given query. >>> >>> Trying in 6.6 to find the Python module "mysqlclient", I get the >>> following puzzling results: >>> >>> $ pkg_info -Q mysql >>> php-mysqli-7.2.24 >>> php-mysqli-7.3.11 >>> php-pdo_mysql-7.2.24 >>> php-pdo_mysql-7.3.11 >>> >>> $ pkg_info -Q py-mysql >>> py-mysql-1.2.5p6 >>> py-mysqlclient-1.4.2p0 >>> >>> Am I doing something wrong? Why is "py-mysqlclient" not matched for >>> the first query? >>> >> >>Hi Dumitru, >> >>Not only isn't "py-mysqlclient" matched, but also over 40 other >>packages with "mysql" string. >> >>How does your $PKG_PATH look like? > >Thanks for looking into it! > >$PKG_PATH is empty here, should have checked it first. I get the >expected results with: > >PKG_PATH=`cat /etc/installurl`/`uname -r`/packages/`uname -m`/ pkg_info -Q >mysql > >But now I don't understand why I got any results at all with an empty >$PKG_PATH... Maybe I would have read that one line in the man page >more carefully if there was no result at all to begin with. :-] >
Re: Best Practices for growing disk partitions on a server
you have to boot in single user mode: https://www.openbsd.org/faq/faq8.html > On 18 Nov 2019, at 00:12, Lev Lazinskiy wrote: > > Hi Edgar, > > Thanks for the response. > On Sun, Nov 17, 2019 at 04:06:18PM -0600, Edgar Pettijohn wrote: >> >> On Nov 17, 2019 2:35 PM, Lev Lazinskiy wrote: >>> >>> Hi folks, >>> >>> I am new to openBSD, so forgive me if I am missing something obvious. >>> >>> I recently installed openBSD on a server using the auto-partition layout >>> during installation and am quickly starting to run out of disk space. >>> >>> I have read the section in the FAQ [1] regarding how to grow a disk >>> partition, but I am confused on the best way to actually do this. >>> >>> Specifically, I am trying to grow /usr and /home but they are "busy" >>> when I try to follow these steps on a running server. >>> >> >> You must umount them first. > > Right, the issue is that I am unable to unmount them because they are > actively being used. >> >> >>> Is the assumption that you are supposed to reboot the server with the >>> ISO attached and pop into a shell to complete these steps? >>> >>> [1] https://www.openbsd.org/faq/faq14.html#GrowPartition >>> >>> -- >>> Lev Lazinskiy >>> >> >> If it's a fresh install probably be easier to just reinstall and size >> partitions how you need them. > > This makes sense, but I was curious what the recommended approach is for > a server that you cannot simply reinstall. > > Someone else suggested using single user mode on boot and that approach > seems to work very well. > >> >> Edgar >
httpd redirect based on query parameters
Hi, I have another question regarding redirects with httpd. I need to redirect a given URL to another server based on its query parameters. Example: http://company.website/products/?id=1 redirect to: "http://newcompany.website/products; http://company.website/products/?id=2 redirect to: "http://newcompany.website/contact; I think the problem is that everything after the "?" is not taking into account by the httpd redirect logic (because by definition it's not part of the path?). But is there a way to achieve this with httpd? Thanks a lot, Thomas
