Re: Need some information about fork(2)
On Mon, Sep 23, 2024 at 9:21 AM Chris Bennett < cpb_m...@bennettconstruction.us> wrote: > So if I run small program A that has some leaks. I don't free a few > things as suggested. Then I run program B that happens to use those > memory addresses that didn't get freed by program A, what happens then? > Are there problems? Or does it just get used properly? > Mostly, things work properly. But 'how' properly depends on the details. If program A terminates, then any resources it didn't explicitly free will be freed automatically and those resources will then be available for re-use. If program A hangs, or sleeps, or spawns B and waits for it to terminate, then the resources A holds won't be released. If program A doesn't run then eventually any memory it holds will be paged out so those pages can be reused by actively running processes, assuming you have swap space. The scenario you give, where B wants to use memory still in use by A, doesn't really happen because A and B each get their own separate virtual address spaces. The same address in A will refer to a different physical page than that same address in B, and the OS will ensure that the physical pages are not shared inappropriately. -ken
Re: Automatic Disk Partitioning
On Sun, Aug 4, 2024 at 6:24 PM David Uhden Collado wrote: > I would like to understand the rationale behind this design choice. Is > there a specific reason why the automatic partitioning is limited to > around 350GB for system partitions? Any insights or explanations you can > provide would be greatly appreciated. > The rationale is that the installer is not able to make a reasonable guess about how you plan to use the system. It knows the minimum required filesystem sizes, and if you have a moderate amount of extra disk it has rules on how to allocate the extra. But if you have an extremely large amount of extra space there's no way to tell what you have planned for it. Are you going to run a database? Maybe the extra space should go into /var. Or better yet, use that extra space to make a new filesystem like /var/mariadb or /var/postgresql. Or maybe you are setting up a web server and you'll want /var/www enlarged. Maybe you will want the extra space in an entirely new directory like /nfs. If the installer can't reasonably guess, it is better to leave the space unused as it's easy to add space somewhere if you have extra, but hard if you don't. The idea here is to start with sane defaults, not immediately paint you into a corner. -ken
Re: pf.conf issue.
On Mon, Jul 15, 2024 at 6:33 AM Irreverent Monk wrote:
> pass in on egress inet6 proto icmp6 all \
>
> icmp6-type { routeradv neighbrsol neighbradv }
>
> pass in on egress inet6 proto udp \
>
> from fe80::/10 port dhcpv6-server \
>
> to fe80::/10 port dhcpv6-client \
>
> no state
>
>
> block all
>
I don't know if this is related to your other issues, but I think the
"block all" here is
cancelling the effect of your inet6 rules.
-ken
Re: Filesystem corruption on OpenBSD routers after power outage?
On Wed, Jul 10, 2024 at 9:45 AM Tom Smyth wrote: > are there other directories that contain files that regularly change > that should be mfs mounted ? > Logs for cron go into /var/cron by default. This can be changed by modifying /etc/syslog.conf, but if you do this don't forget to update /etc/newsyslog.conf as well. -ken
Re: Offline syspatch
On Sat, Jun 29, 2024 at 3:29 AM jonathon575 wrote: > For the current release 7.5, specifically for security patches, if we > downloaded the security patches located at any of the mirror links, for > example, > > https://mirror.hs-esslingen.de/pub/OpenBSD/syspatch/7.5/amd64/ > > manually verified the signature with signify, then changed the online path > under /etc/installurl to point to the usb/location that contains the > downloaded security patch files, and then executed the command syspatch, > usually, the security patch files gets pulled from the pointed physical > location and gets updated, however, my question is, would that be > sufficient for patching the system, or do we actually have to compile from > source and include the security patch files in the compilation process? > It is my understanding that it will work as you desire. Modifying /etc/installurl allows you to specify which mirror you want to download from, and if you choose to maintain your own private mirror with only a subset of files you can do so. Note that, iirc, /etc/installurl should point to a directory that contains a "syspatch" subdirectory which contains a "7.5" subdirectory, etc. Do not point /etc/installurl directly at the folder containing the syspatch files, point it at the root under which you are mirroring the structure of an official mirror. Your private mirror can contain releases, patches and syspatches for multiple versions and architectures, and the directory structure is needed to keep those things separated and locatable. -ken
Re: sshd /var/empty
On Tue, Jun 18, 2024 at 4:14 PM 4 wrote: > i'm sorry, i'm not smart, but i have a several questions. imagine that we > launch a ship far into space. we have only one communication channel with > this ship, and one day, when the ship is already very far away from us, > communication channel stops working [...] > You did something wrong. It's pretty apparent from the tone of your message you don't want help identifying what it was or how to fix it, but for the benefit of others who find this thread in the future, read the sshd_config man page to find out how to use the ChrootDirectory option correctly. -ken
Re: obsd wifi
On Sat, May 4, 2024 at 2:05 PM Gustavo Rios wrote: > I have just installed OpenBSD in my brand new notebook. It is a dell > notebook that came with just a wifi NIC. How do i discover the name o my > wifi nic ? > If your nic is supported, it will appear in the list of configured network interfaces if you run the "ifconfig" command. To determine which one is wireless if you don't know, you can check the man page for each type of interface to see what they are. For example, if you see you have "lo0", "em0" and "iwm0" interfaces, you can use the commands "man lo", "man em", and "man iwm" to discover what each one is. You can also get information about interfaces by seeing what information was printed about them when the system was booted. Use the "dmesg" command to review these messages. -ken
Re: No internet after connecting to wifi
On Wed, Mar 20, 2024 at 2:17 PM Patcher wrote: > Hello, > > I am having problem connecting to internet in my openbsd desktop. During > installation I was unable to connect to my mobile hotspot (don't have > wifi). I didn't pay much attention to it and continued to installation. > After installation I went to install firmware for my wifi card (cheap wifi > dongle using mtw firmware) using android usb tethring. After doing a > fw_update, I tried to connect to mobile hotspot using ifconfig utility as > stated in faq I did ifconfig mtw0 nwid xyz wpakey xyz and ran the command. > After that I did ifconfig mtw0 inet autoconf. I tried to ping openbsd.org > but it din't worked. Here are the outputs of dmesg, netstat -rn and > ifconfig. Any help will be appreciated. > > [...] > > mtw0: flags=808843 mtu > 1500 > lladdr 00:e0:2d:4c:73:7f > index 3 priority 4 llprio 3 > groups: wlan > media: IEEE802.11 autoselect (DS1 mode 11g) > status: active > ieee80211: join net chan 1 bssid ea:ed:fb:e9:27:74 -37dBm wpakey > wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp > I don't see an "inet" line showing that you have an IP address assigned on this interface. Do you have a DHCP server you are expecting to give you an address? If so it hasn't. Also make sure dhcpleased(8) is running. It should be already, but it doesn't hurt to check. -ken
Re: can't find PID
On Tue, Mar 5, 2024 at 12:24 PM Markus Wernig wrote: > When I reload the pf ruleset with pfctl, the number in the pid field > changes. So my assumption is that it is the pid of the pfctl process > that inserted the rule. Is that correct? > I believe you are correct. while running tcpdump in another window, I tested this for myself by running: # pfctl -f /etc/pf.conf & [1] 27982 The pid shown in the tcpdump output immediately changed from its previous value to 27982. I assume that this feature is most useful when specific rules are updated via anchors, e.g. for ftp-proxy. -ken
Re: mirror.bytemark.co.uk appears to have removed all OpenBSD content?
On Mon, Feb 26, 2024 at 9:01 PM Peter Kay wrote: > Fortunately there's a couple of archives with pretty much every > OpenBSD release ever, so sysupgrade is currently rather busy > Slightly off topic, but does anyone know of any archives that have packages for 3.0, 3.1, 3.2, and/or 3.3? Especially 3.0 -- the only site I've ever found with 3.0 packages may have been incomplete. -ken
Re: No dhcp renewal of IP
On Sun, Feb 18, 2024 at 4:15 AM Marcus MERIGHI wrote: > Hello, > > this is not to answer the original question, but... > > kgo...@gmail.com (Kenneth Gober), 2024.02.17 (Sat) 22:15 (CET): > > On Sat, Feb 17, 2024 at 10:47 AM Luis Mendes > wrote: > > > The interface ure0 is the gateway to the Internet, connected to the > ISP. > > > Somehow, when this interface loses the IP, the lease is not renewed. > > > > This is the rule I would use in my pf.conf to allow my router to send > DHCP > > requests to my ISP: > > > > pass out log quick on ure0 inet proto udp from (ure0) port bootpc to any > > port bootps > > this is not necessary, because: > > "dhcpd reads packets off the wire using BPF, which happens as > packets come off the network interface, but before the IP stack > where pf runs." > David Gwynne 17 Dec 2022 > https://marc.info/?l=openbsd-misc&m=167128237931458 > > Marcus > dhcpd(8) is the DHCP server. It listens for DHCP/BOOTP requests on the network. The original question was about the DHCP client (dhcpleased(8) or dhclient(8)) and renewals, which are packets sent out to the network. Those packets do pass through pf when being sent (as far as I know) although at the other end whatever server you are sending to might be using BPF to read them. It is true that dhcpleased(8) and dhclient(8) may use BPF to receive responses from DHCP servers, but you will never receive any response if your requests are blocked before they can even leave your machine. This is why I have a 'pass out' rule. It is to allow DHCP requests to be sent *out* to the network. -ken
Re: No dhcp renewal of IP
On Sat, Feb 17, 2024 at 10:47 AM Luis Mendes wrote: > The interface ure0 is the gateway to the Internet, connected to the ISP. > > Somehow, when this interface loses the IP, the lease is not renewed. > This is the rule I would use in my pf.conf to allow my router to send DHCP requests to my ISP: pass out log quick on ure0 inet proto udp from (ure0) port bootpc to any port bootps I need this because I block all inbound *and* outbound traffic on my router by default. Without seeing your PF configuration it's unclear whether this rule would help you and I do not recommend you ever copy/paste settings on your router that you don't understand. But if you do understand what this rule does and can guess why you need it, feel free to try it. -ken
Re: Out of memory error when build OpenBSD Base/LLVM
On Sat, Feb 17, 2024 at 10:07 AM Shivam Gupta wrote: > I recently installed OpenBSD OS on my ASUS laptop quad core pentium with 4 > GB RAM and 1 TB HDD. > > I was following the guide to build the system from source. But in `make > build` step it gets a memory error when building LLVM. > I have built OpenBSD 7.4/i386 on a VM with 512MB RAM, and 7.4/amd64 on a VM with 1GB RAM, so 4GB ought to be plenty. Both VMs were configured with two CPU cores. Maybe the build process is trying to do too many things at once, and your slow CPUs are exposing race conditions not normally seen? Try booting bsd.sp and see if the build completes using only one CPU. -ken
Re: Partition completely wiped out, why?
On Wed, Jan 10, 2024 at 7:44 PM Jonas Bechtel wrote: > After mounting with right ufstype, I saw right data. (Probably this is > what I remember. Files in root directory looked well there) > > In installation I went to manual disklabel edit. One of the steps there > was to assign the mount point /oldbsd5 there. > I think this is where you went wrong. During installation, when you are asked to edit the disklabel, the installer is going to erase every partition you define in preparation for installing OpenBSD onto your new empty partitions. If you want to keep a portion of the disk untouched (e.g. because it had data from before that you will want to continue to access later) what you need to do is leave that space unallocated, then after OS installation is completed you can edit the disklabel to define the additional partitions. TL;DR - when you are at the disklabel step in the installer, you are not being asked to declare partitions you want to keep, you are being asked to define partitions that you want wiped clean in preparation for your new OS install. -ken
Re: installboot sd0 fails while installing from USB drive
On Sun, Dec 31, 2023 at 11:07 AM Kenneth Gober wrote: > On Mon, Dec 25, 2023 at 6:08 PM Gábor Papp wrote: > >> I am trying to install OpenBSD 7.4 on my ThinkPad L390. This bug only >> happens on this certain laptop. >> I could install OpenBSD 7.3 just fine on this machine, so I think this >> is a bug happens because of this weird combination of 7.4 and maybe a >> firmware update. >> > > I haven't been able to install 7.4 on my ThinkPad L390 Yoga, but it does > boot > 7.4/amd64 from USB just fine. So you could perhaps try doing the install > to > another USB stick, then using dd to copy the completed installation to the > internal drive. Actually I recommend first trying the install again; > maybe it was > just a one-time thing and won't turn out to be reproducible. > I found some time to install a spare SSD in my L390 Yoga and tried installing 7.4/amd64 on it, and it installed with no trouble. So any issue is likely to be very specific to your exact setup and process. Or it was a one-time thing. Here's the dmesg from the install. It is essentially the same as in my previous message except this time I had no network connection so I didn't get firmware updates. I don't see how that would have affected installboot, however. Also the dmesg from the first boot after install follows after this one: OpenBSD 7.4 (RAMDISK_CD) #1322: Tue Oct 10 09:07:38 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 16725819392 (15950MB) avail mem = 16214888448 (15463MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x4ce2e000 (60 entries) bios0: vendor LENOVO version "R10ET43W (1.28 )" date 12/27/2019 bios0: LENOVO 20NUS1S800 acpi0 at bios0: ACPI 6.1 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT UEFI SSDT HPET APIC MCFG ECDT SSDT BOOT SLIC SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB DMAR NHLT ASF! FPDT UEFI 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) i5-8365U CPU @ 1.60GHz, 1590.02 MHz, 06-8e-0c, patch 00ca 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,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,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,TSX_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 6MB 64b/line 12-way L3 cache cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpiec0 at acpi0 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 -1 (RP05) acpiprt6 at acpi0: bus -1 (RP06) acpiprt7 at acpi0: bus -1 (RP07) acpiprt8 at acpi0: bus -1 (RP08) acpiprt9 at acpi0: bus 3 (RP09) acpiprt10 at acpi0: bus -1 (RP10) acpiprt11 at acpi0: bus -1 (RP11) acpiprt12 at acpi0: bus -1 (RP12) acpiprt13 at acpi0: bus 5 (RP13) acpiprt14 at acpi0: bus -1 (RP14) acpiprt15 at acpi0: bus -1 (RP15) acpiprt16 at acpi0: bus -1 (RP16) acpiprt17 at acpi0: bus -1 (RP17) acpiprt18 at acpi0: bus -1 (RP18) acpiprt19 at acpi0: bus -1 (RP19) acpiprt20 at acpi0: bus -1 (RP20) acpiprt21 at acpi0: bus -1 (RP21) acpiprt22 at acpi0: bus -1 (RP22) acpiprt23 at acpi0: bus -1 (RP23) acpiprt24 at acpi0: bus -1 (RP24) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 "INT33D3" at acpi0 not configured "ACPI0003" at acpi0 not configured "LEN0268" at acpi0 not configured "PNP0C0A" at acpi0 not configured "PNP0C60" at acpi0 not configured "LEN0100" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT34BB" at acpi0 not configured "INT3515" at acpi0 not configured "ACPI000E" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT0E0C" at acpi0 not configured "PNP0C0E" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT33A1" at acpi0 n
Re: installboot sd0 fails while installing from USB drive
On Mon, Dec 25, 2023 at 6:08 PM Gábor Papp wrote: > I am trying to install OpenBSD 7.4 on my ThinkPad L390. This bug only > happens on this certain laptop. > I could install OpenBSD 7.3 just fine on this machine, so I think this > is a bug happens because of this weird combination of 7.4 and maybe a > firmware update. > I haven't been able to install 7.4 on my ThinkPad L390 Yoga, but it does boot 7.4/amd64 from USB just fine. So you could perhaps try doing the install to another USB stick, then using dd to copy the completed installation to the internal drive. Actually I recommend first trying the install again; maybe it was just a one-time thing and won't turn out to be reproducible. Here is what the dmesg looks like booting a completed 7.4/amd64 installation on my L390 Yoga (dmesg from booting RAMDISK_CD follows after): OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec 8 15:39:04 MST 2023 r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ GENERIC.MP real mem = 16725819392 (15950MB) avail mem = 16199168000 (15448MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x4ce2e000 (60 entries) bios0: vendor LENOVO version "R10ET43W (1.28 )" date 12/27/2019 bios0: LENOVO 20NUS1S800 efi0 at bios0: UEFI 2.6 efi0: Lenovo rev 0x1280 acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT UEFI SSDT HPET APIC MCFG ECDT SSDT BOOT SLIC SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB DMAR NHLT ASF! FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(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) i5-8365U CPU @ 1.60GHz, 1691.55 MHz, 06-8e-0c, patch 00f8 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,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,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,TSX_CTRL,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,RRSBA,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 6MB 64b/line 12-way L3 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) i5-8365U CPU @ 1.60GHz, 1504.19 MHz, 06-8e-0c, patch 00f8 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,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,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,TSX_CTRL,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,RRSBA,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 6MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz, 1496.52 MHz, 06-8e-0c, patch 00f8 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,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,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,TSX_CTRL,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,RRSBA,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 6MB 64b/line 12-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz, 1496.52 MHz, 06-8e-0c, patch 00f8 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,S
Re: Hardware RAID on Poweredge Servers
On Thu, Mar 30, 2023 at 12:37 PM Kihaguru Gathura wrote: > Is hardware RAID on Poweredge servers (T340, PERC H330 in particular) > generally stable enough for production or is it safer to stick with OpenBSD > softraid? > I haven't used the H330, but the PERC 5/i and the PERC H700 have worked fine for me. In terms of 'safety' I advise having a spare controller on hand because if your controller fails recovery will be simplest if you have the same controller (with the same firmware version) on hand. Note that mounting a RAID volume on a newer controller (or the same controller with newer firmware) may prevent that volume from being attached to an older controller later. So don't try doing fancy things like moving the drives to a newer system to take a backup, then trying to move them back to their original system later unless you have the same controller in both systems. In general I prefer hardware RAID because it's more likely you'll be able to easily boot your system if the array is running in a degraded state due to a drive failure (perhaps you might need to press F1 or something to continue). With softraid, you might need to type special commands at the console to force booting or mounting a volume with a failed drive in it. This may be a problem if you are in a rush to bring the system back up and don't have a convenient way to look up the necessary commands. -ken
Re: disabling horizontal scroll in ksh
On Sun, Mar 19, 2023 at 7:36 AM sewn wrote: > hi, i've recently switched to ksh and i've been very annoyed by the > horizontal scroll feature (happens when a commmand is longer than the > terminal's width) is there anyway to disable this feature? i would > prefer > to see the whole command, like in bash or ash. > If you disable command line editing it will stop this. For me, the command "set +o emacs" did it. -ken
Re: redirection puzzle
On Fri, Dec 2, 2022 at 10:17 AM wrote: > I needed to show the stdout of a command as well as pass > it to another command's stdin. This works: > > odin:~$ echo 1 | tee /dev/ttyp8 | sed 's/1/2/' > 1 > 2 > odin:~$ > > where /dev/ttyp8 is the result of the tty command: > Have you considered: $ echo 1 | tee /dev/tty | sed 's/1/2/' See the end of the man page for tty (4) for an explanation of /dev/tty. -ken
Re: faq/faq6.html#Wireless : nwid vs join
On Mon, Oct 17, 2022 at 5:37 AM tux2bsd wrote: > > nwid puffyuberalles wpakey passwordhere > > inet autoconf > > > > Or, for multiple access points: > > > > join home-net wpakey passwordhere > > join work-net wpakey passwordhere > > join cafe-wifi > > inet autoconf > > It isn't clear why one uses 'nwid' and the other uses 'join', > I think it would be better to be consistent for either use case - > all 'nwid' or all 'join' (I prefer 'join'). > Not every detail gets into the FAQ. The difference between 'join' and 'nwid' is described in the ifconfig(8) man page. 'join' is used to add a network to the 'join list' which is a list of networks the system will try to connect to, when not already connected to another network. 'nwid' is used when you want to immediately connect to an access point without disturbing the join list. For example, you might use 'nwid' to connect to a public network such as one provided by a hotel or a cafe, without modifying your 'join' list which might normally have only your private home and office networks. -ken
Re: dump(8) is slow
On Tue, Aug 9, 2022 at 8:25 AM Christian Weisgerber wrote: > Moving 9TB with dump|restore from an old hard disk to a bigger one > reminded me again that dump(8) is, well, slow: > > DUMP: 9104433830 tape blocks > DUMP: Date of this level 0 dump: Sat Aug 6 16:36:52 2022 > ... > DUMP: Date this dump completed: Tue Aug 9 13:51:01 2022 > DUMP: Average transfer rate: 36530 KB/s > In my experience, dump(8) runs up to twice as fast if you use the "-b 64" option, unless you hit a hardware bottleneck first. I haven't tested lately, but two years ago I was getting these results dumping a 1TB volume from a 4-drive hardware RAID10 array to various destinations: 096724 KB/s/dev/null 199562 KB/s/dev/null (-b 64) 046365 KB/sLTO4 SAS 056925 KB/sLTO4 SAS (-b 64) 088129 KB/sLTO4 SAS external (-b 64) 050710 KB/sLTO5 FC 8Gbps 101542 KB/sLTO5 FC 8Gbps (-b 64) Are you certain that dump(8) is the big bottleneck here? My recollection is that restore(8) is significantly slower, so of course if restore(8) is slow reading from the pipe then whatever is writing to the pipe at the other end will stall. -ken
Re: rpki-client disk utilization / noting mfs in man?
On Sun, Jul 31, 2022 at 8:35 AM Tobias Fiebig < tob...@reads-this-mailinglist.com> wrote: > > You could periodically rsync it to permanent storage and use mount_mfs' > > -P option to populate at boot. > Really good point; I will give setting that up a try later today and add > that to the > blogpost. > In addition to a scheduled rsync job, don't forget to also put that same rsync command into /etc/rc.shutdown, so that a controlled reboot or shutdown will update persistent storage with the most up-to-date data. The scheduled rsync commands will then just be there to ensure you don't lose too much in case of system lockup or other uncontrolled reboot/powerfail/etc. -ken
Re: Freeze on OpenBSD 7.1
On Sun, Jul 17, 2022 at 4:51 PM wrote: > Hello, > > I encounter a freeze on my OpenBSD 7.1 router. I have to reboot it. When > that happens, there's nothing special in the /var/log/messages file : > Jul 17 06:00:01 system syslogd[8620]: restart > Jul 17 21:00:25 system syslogd[97469]: start > Jul 17 21:00:25 system /bsd: OpenBSD 7.1 (GENERIC) #443: Mon Apr 11 > 17:55:15 MDT 2022 > > That happened several times. At first I thought that was a temperature > related issue. So I installed a large USB fan on the case, and the case is > at the room temperature of 25°C. I don't know how to diagnose that issue. > Do you have a monitor attached to your router? If not, attach a monitor so you can see any error messages that may be displayed on the console. In particular, if the freeze is due to a panic, you will need to be able to see the console display to diagnose it. -ken
Re: mSATA in APU2D0
On Wed, Jul 6, 2022 at 7:33 AM Jan Stary wrote: > This is current/amd64 on an APU2D0, dmesg below > Everything runs just fine from a SD card. > > My problem is it does not boot with this mSATA disk in. > The leds of the mSATA and the leds of the APU keep blinking, > the console keeps repeating > > PC Engines apu2 > coreboot build 2006 > BIOS version v4.17.0.1 > > and it never gets past that. > It has booted _once_, but not since. > > Without the mSATA, it boots fine. > I have tested the mSATA disk in other machines > and adaptors and it seems to work fine. > > Is this some kind of HW incompatibility? > How can I debug what's happening? > I have run 6.4/amd64, 6.7/amd64, 6.8/amd64 on an APU2E4 from mSATA, and I've run 6.4/amd64 on an APU2D4 from mSATA. All machines worked fine, but I did not have SD cards installed in any of them. The OS install was done directly to the mSATA devices, booting from a USB stick. All of my mSATA devices are small, either 30GB (from PC Engines) or 32GB (Innodisk). using mSATA only I did not have to change anything in the BIOS regarding boot order. I have 3 suggestions: First, there might be a compatibility issue with coreboot. I can confirm that Coreboot build 20170228/SeaBIOS 1.10.0.1 worked for me on both the APU2D4 and the APU2E4. Second, based on the constant rebooting I am guessing that the BIOS is having trouble recognizing and/or loading the boot loader. If you did a UEFI install, try MBR. If it's MBR, make sure your OpenBSD slice is marked active (i.e. the one to boot from). Third, try installing 6.8 to be sure it's not something specific to -current. I would normally suggest 7.0 or 7.1 but I have not had time to upgrade any of my APU systems to anything newer than 6.8, so I cannot personally attest that mSATA definitely works in 6.9+. -ken
Re: Question to usbdevs and dmesg
On Sun, Nov 14, 2021 at 9:18 AM Sven Wolf wrote: > I've attached an XBOX 360 controller to my system. > The controller gets detected as: > usbdev: > addr 02: 045e:028e \M-)Microsoft Corporation, Controller > > dmesg: > uhidev1 at uhub1 port 1 configuration 1 interface 0 "\M-)Microsoft > Corporation Controller" rev 2.00/1.14 addr 2 > > ugen1 at uhub1 port 1 configuration 1 "\M-)Microsoft Corporation > Controller" rev 2.00/1.14 addr 2 > > Do you have an idea why the controller is detected as > "\M-)Microsoft Corporation, Controller" and not as > "XBOX 360 Controller" as it is defined in > /usr/src/sys/dev/usb/usbdevs > "vendor MICROSOFT 0x045e Microsoft" > "product MICROSOFT XBOX360_CONTROLLER 0x028e XBOX 360 Controller" > That is probably the name reported by the controller itself. Ben Eater has a pretty good video on YouTube covering USB device discovery: https://www.youtube.com/watch?v=N0O5Uwc3C0o The bit about retrieving descriptors from the device is about 16 minutes in. -ken
Re: Applying scan_ffs output to disklabel?
On Sun, Aug 29, 2021 at 5:35 PM Jason Morris wrote: > I'm in the process of recovering my drive (fat fingered dd and blew away > the partitions). I've obtained the following output from scan_ffs but not > sure how to apply this to recreate the disklabel. Running disklabel -R with > this output doesn't seem to work. > > fuguita# scan_ffs -lv sd2c > block 128673234 id a86900, 1d53400 size 30225408 > block 150903347 id 8,0 size 76481934 > block 475612813 id 502b55c2,800e9b02 size 1130083924 > block 587802509 id 502b55c2,800e9b02 size 1130083924 > block 867995213 id 502b55c2,800e9b02 size 1130083924 > block 1338443597 id 502b55c2,800e9b02 size 1130083924 > block 1638543507 id abbbeaf9, b4ab0641 size 472173501 > scan_ffs:_read: Invalid argument > According to the man page, scan_ffs will work only on FFS file systems, not FFS2. Since FFS2 is now the default, presumably scan_ffs wasn't able to find any file systems. If it had found something, it would have output one or more lines looking something like these: X: 524224 64 4.2BSD 2048 16384 1 # / X: 4194304 524288 4.2BSD 2048 16384 1 # /usr X: 1048576 4718592 4.2BSD 2048 16384 1 # /usr/local There should be a backup of your disklabel in /var/backups/disklabel.sd2.current (or sd0, or sd1, etc. as appropriate depending on how things were configured previously). If you have backups, the easiest thing to do is look through those backups to find this file. If you don't have backups, here is an example of what one of these disklabel files might look like; you might be able to find it on your disk just by reading blocks until you find it (assuming it's not encrypted): # /dev/rsd0c: type: SCSI disk: SCSI disk label: DELL PERC H700 duid: 26daa7a4492ed6e9 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 36404 total sectors: 584843264 boundstart: 100759680 boundend: 584830260 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 1028160100759680 4.2BSD 2048 16384 8000 # / b:131604480101787840swap# none c:5848432640 unused d: 4112640233392320 4.2BSD 2048 16384 12958 # /usr e: 2056320237504960 4.2BSD 2048 16384 12958 # /usr/local f: 1028160239561280 4.2BSD 2048 16384 8000 # /var g: 16450560240589440 4.2BSD 2048 16384 12958 # /tmp h: 411264025704 4.2BSD 2048 16384 12958 # /home i:64197 63 unknown j: 5121522064260NTFS k:197406720261152640 4.2BSD 2048 16384 12958 # /var/postgresql Note that a 'normal' installation of OpenBSD will typically have a much smaller boundstart value, like 64. The system I took this sample from has both Windows and OpenBSD on it so the layout is a bit unusual. -ken
Re: NAT on same interface as vlan on OpenBSD 6.8
On Mon, May 10, 2021 at 5:26 AM Dirk Coetzee wrote:
> I am hoping to create a pf.conf configuration that has VLAN’s and NAT via
> the same (physical) interface. The hardware is only capable of having a
> single Ethernet interface.
>
> vlan100 is an isolated network to setup servers and is connected to a
> switch that is setup for vlan100 and vlan 1. The same interface has the
> main internal IP address 192.168.10.241 ("vlan 1" / no vlan). Devices
> behind vlan100 network need to be NAT’ed behind the internal / corporate
> interface 192.168.10.241, so that they can still have internet access -
> without affecting the main / corporate network.
>
> pass out quick log on $int_if
> match out on $int_if inet from $vl100_net to any nat-to $int_ip source-hash
>
I believe your issue is that the "pass out quick" takes effect immediately
and rules that come later aren't checked. Either remove the 'quick' or
move the 'match out' NAT rule so that it's above the 'pass out quick'.
Some people don't like to use 'quick' because it makes "last match"
semantics hard to follow (it's an exception to keep track of if most of
your ruleset is structured for 'last match wins'). I prefer to use 'quick'
on almost all of my rules to get "first match" semantics because I find
'first match wins' easier to work with (it means that the remainder of the
ruleset after a matching 'pass' is irrelevant and need not be examined).
It is purely personal preference on whether you prefer to read your rules
from the bottom up or the top down. If you want to continue to use 'quick'
the most expedient fix is to move the 'match out' so that it comes before
your first 'pass out' rule.
-ken
Re: [Ver3.6/3.9] Old version need help
On Tue, Mar 30, 2021 at 4:06 AM cclai wrote: > So I hope that your organization can provide > an installation package "3.6 and 3.9 version" to solve the problem. > CD copies of 3.6 and 3.9 are still available for purchase from Computer Shop of Calgary but there is an issue with their web site so you'll need to email cshop (at) computershop.ca to place an order. If you want to see a list of what's for sale, archive.org has that page: https://web.archive.org/web/20190222064326/http://computershop.ca/cgi-bin/eStore I ordered a couple of old versions myself in December to fill some gaps in my collection, so I can confirm that purchases are still possible. There is some shipping delay due to the pandemic of course, so in the short term get a copy from one of the archives that still has it. In the long term, if your organization is depending on those versions then you should have physical copies that you can keep yourself. You cannot rely on archives having old releases forever. This is especially true for packages -- even ftp.nluug.nl no longer has a complete package archive for releases 3.0, 3.1, 3.2 and 3.3. I haven't found a complete package archive for 3.0 anywhere. -ken
Re: Samba server : issue with file transfer from Windows network with share special properties
On Mon, Mar 22, 2021 at 9:11 AM jeanfrancois wrote:
> It has sometimes error messages when copy which I tracked to being from
> Windows network to the Samba server where source files or folders's
> properties are not supported (like archiving option).
>
> Has someone a fix for this, or can point out what I may have missed ?
Consult the smb.conf man page ("man smb.conf") and read about the
"map readonly", "map archive", "map hidden" and "map system" options.
These may help you.
-ken
Re: OpenBSD as a NAS
On Wed, Dec 2, 2020 at 6:19 PM Ashton Fagg wrote: > a) Is softraid reliable enough to support my use-case? Does anyone have > anecdotes to encourage/discourage use of softraid for this application? > I believe softraid is reliable enough, but I don't use it so I can't say so from personal experience. I do use Samba and NFS though and can report that those work acceptably well. Reading a large file via Samba over a gigabit link runs at between 30MB/s and 110MB/s in OpenBSD 6.8. This is a big improvement over older OpenBSD releases. > b) Would I be better off using the LSI RAID controller for the arrays? > I do, but mostly because I want to use RAID10 which is not officially supported in OpenBSD softraid. It's also nice to be able to take advantage of the battery backed delayed write cache on my controller (a Dell PERC H700 in my case). One thing you might find important is that using hardware RAID makes it harder to closely monitor controller and disk status, since the controller vendor provided software typically won't work on OpenBSD. If your drive enclosure supports alert LEDs then keeping an eye on those indicators may be the easiest way to monitor array health. c) Bearing in mind that the provisioning scheme I have in mind is to > provision the disks in pairs (forming RAID1 arrays), thus resulting in > 3-4 separate volumes (6-8 disks), is there any reason I should *not* use > OpenBSD, and look more toward something like TrueNAS or FreeBSD? > I suspect that the OpenBSD port of Samba will give you more challenges than OpenBSD itself. I suggest setting up a small test server and verifying client compatibility (including user authentication) before building the full server. -ken
Re: Multiple USB NICs
On Tue, Nov 17, 2020 at 8:15 AM Mihai Popescu wrote: > Lee Nelson wrote: > > > If I have multiple USB Ethernet adapters of identical make and model, > > how does OpenBSD distinguish them over time. > > Is this happening to APU with same hardware interfaces, too? > No, 'wired in' interfaces are initialized in a predictable sequence. NICs installed in, e.g., PCI or PCIe slots also get consistent numbering. If you have multiple NICs installed the numbering might change if you remove one (i.e. fxp1 might become fxp0 if you remove the old fxp0). -ken
Re: Large Filesystem
On Sun, Nov 15, 2020 at 8:59 AM Mischa wrote: > On 15 Nov at 14:52, Otto Moerbeek wrote: > > fsck wil get slower once you start filling it, but since your original > > fs had about 104k files it expect it not getting too bad. If the speed > > for your usecase is good as well I guess you should be fine. > > Will see how it behaves and try to document as much as possible. > I can always install another BSD on it. ;) > To give a very rough idea, here is a sample running fsck on an FFS2 file system with a fairly large number of files: $ df -ik /nfs/archive Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/sd1g 12308149120 7477490128 421525153664% 4800726 383546408 1% /nfs/archive $ doas time fsck -f /nfs/archive ** /dev/sd1g (6d3438729df51b22.g) (NO WRITE) ** Last Mounted on /nfs/archive ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 4800726 files, 934686266 used, 603832374 free (35534 frags, 75474605 blocks, 0.0% fragmentation) 3197.25 real35.86 user66.03 sys This is on older hardware, and not running the most recent release. The server is a Dell PowerEdge 2900 with a PERC H700 controller, and 4 WD Red Pro 8TB disks (WD8001FFWX-6) forming a RAID10 volume containing 3 small 1TB file systems and 1 large 12TB file system. The OS is OpenBSD 6.1/amd64. All the file systems on this volume are mounted with the softdep option and the big one has noatime as well. The time to run fsck is really only an issue when the server reboots unexpectedly (i.e. due to a power outage). Coming up after a proper reboot or shutdown is very fast due to the file systems being clean. A UPS can help avoid most of these power-related reboots. Alas, this particular server was connected to a UPS with a bad battery so it has rebooted due to power outages at least a half-dozen times this year, each of them involving a fairly long fsck delay. I finally took the time last week to replace the UPS batteries so going forward this should be much less of a problem. I do recommend the use of a UPS (and timely replacement of batteries when needed) if you are going to host very large FFS2 volumes. I have never lost files due to a problem with FFS2 (or with FFS for that matter), but that is no reason not to perform regular backups. For this particular file system I only back it up twice a year, but the data on it doesn't change often. File systems with more 'normal' patterns of usage get backed up weekly. The practice of taking regular backups also helps ensure that 'bit rot' is detected early enough that it can be corrected. -ken
Re: Creating a Partition for RAID Arrays
On Wed, Sep 16, 2020 at 11:52 PM Justin Noor wrote: > We need to create a partition on an OpenBSD server for the sole purpose of > mounting RAID arrays. > > The mount point would be something like: > > /data > > Then we will create directories in that partition and mount the arrays: > > /data/raid1 > /data/raid2 > /data/raid3 > If you are mounting the arrays over the network via NFS or iSCSI then you don't need to make /data its own partition. Just make a folder in the root directory, and create the desired sub-folders within. When the RAID array isn't mounted, the directory will be empty, consuming no space. When the RAID array gets mounted, the space will come from the RAID array itself. If the arrays are local (RAID controller installed in this server) then you will create the partitions *on* the RAID arrays after you create them. Each RAID array will appear to OpenBSD as a separate disk, needing its own partition table. -ken
Re: dump LOB status
On Tue, Sep 15, 2020 at 12:04 PM Jose Soares wrote: > I am facing this when issuing the dump command of a "large" file system > (2.7TB). > dump command has finished successfully for the other smaller file systems. > > On Tue, Sep 15, 2020 at 4:47 PM Stuart Henderson > wrote: > > On 2020-09-15, Jose Soares wrote: > > > DUMP: Child 97414 returns LOB status 213 > > > > > > Could you please explain the meaning of "LOB status 213"? > > > > LOB=low-order byte > > > > What 213 represents, I'm not sure... > I took a very quick look at the source and it appears that 213 is shown in octal. I believe that the 200 bit indicates that a core file was produced, and 13 is probably a signal number (13 octal equals 11 decimal which would be SIGSEGV). I am not sure whether the size of the file system is itself the cause, I have been using dump(8) to back up a large (currently 6.7TB) volume to tape for years (several tapes, actually) and it works fine, although that system is still on 6.1/amd64. I looked in CVS and didn't see any obvious diffs between 6.1 and 6.6 that jumped out at me as potential causes, so perhaps the issue has been latent for a long time and I haven't seen it because it's triggered by the particulars of one or more files rather than the overall file system size. Maybe if an individual file gets too big, or is too 'sparse' or something? -ken
Re: Crashing 64bit (AMD) 6.7 kernel on APU2
On Sun, Aug 30, 2020 at 2:55 AM Damian McGuckin wrote: > This is on an APU2 with an AMD64 release. > > Has anybody seen the same problem? > I have an APU2E4 running 6.7/amd64 and haven't had any trouble with it. I also have two running 6.6/amd64, one running 6.4/amd64, and an APU2D4 running 6.4/amd64. None of them have exhibited any problems. All of them are running the factory firmware (Coreboot build 20170228 / SeaBIOS version 1.10.0.1 -ken
Re: Can I boot without GPU ("headless")?
On Fri, Aug 28, 2020 at 3:32 PM Henry W. Peterson < henrywillpeter...@outlook.com> wrote: > Do I need a graphics card installed all the time? > > The motherboard has pins for a COM serial port, during installation I was > asked if I wanted "com0" to become the default console. I said no. > I believe the requirement is that the system always needs a console device. The console device does not need to use a graphics card, however; a serial port is an acceptable console. I am guessing the problem you are having is you said no to using a serial console on com0, then removed the video card so you couldn't have a wscons console either. If you had answered yes to setting com0 to be the default console, things would probably have worked. There are several i386/amd64 systems that are sold without graphics hardware, e.g. the PC Engines APU2, and the Soekris systems while they were still available. They work fine using com0 as the console. -ken
Re: DHCPD issue
On Mon, Jul 20, 2020 at 3:06 AM Charlie Burnett wrote: > 1. I cannot connect to the internet properly unless only em0 (which is the > ethernet port I have connected to the external network) has a hostname > file- I have to either add back the hostname files after boot and run > /etc/netsetup or manually set up the internal network ports through > ifconfig. > I am guessing (due to lack of details) that your issue is that you are running a DHCP client on multiple interfaces, and as a result you are ending up with multiple default routes. It is normal when getting an IP address with DHCP to be provided with a default route, so if you're using DHCP to get an IP address from your upstream provider you should not also use DHCP on any internal interfaces (unless you want to server DHCP as a DHCP server). Static IP address assignments on your internal interfaces will work fine. 2. Even once the box is connected properly to the network, its' seemingly > unable to assign leases to other clients, attempting to connect to it > through another OpenBSD machine results in it timing out while getting a > lease. > I cannot guess the issue here without seeing your dhcpd.conf. > 3. Using the same exact config, I ran it behind a standard proprietary > router (linksys) that connects fine externally. Using that, the box > functions as expected. > 4. Using an openwrt router I get similar errors. Are the Linksys and Openwrt routers serving the same IP address ranges to DHCP clients? If not, it's possible that the one that's not working is using the same subnet as you have assigned to an internal interface on the APU2. 5. I'm using both config that I've used on external networks as well as > subnetworks on a corporate network that worked, and the default config from > the setting up a router page for a sanity check. > It is unclear what the outcome was here, and without knowing how those external and corporate networks were set up, I'm not able to guess what those configs might have been. In terms of useful information you could just as well have said "I tried something random but I'm not going to tell you the result." > 6. I assumed it was DHCP, but nonetheless as a sanity check I had pf pass > through anything and everything, worked internally as well as externally. > I'm at a complete loss- seeing as it occurs on openwrt I assume that its' > probably because of however the hell my landlord set up the network, but > anyone remotely have an idea how to begin debugging this? I don't like > particularly having a proprietary router running especially without a > firewall I trust. > The way you debug this is to first establish that you have Internet connectivity as an endpoint. Don't worry about routing at all. Once that is confirmed working then you can enable your internal interfaces and turn on forwarding. Once you're sure that routing is working, you can then start offering internal services like DHCP and DNS. If you use a default deny/deny PF policy (both block in and block out by default) keep in mind that you may need to explicitly add pass out rules to allow things like the DHCP client to work. Remember that a default block out rule will block both forwarded traffic trying to go out the egress interface, as well as non-forwarded traffic that originates from the router itself (like DHCP requests, DNS requests, NTP requests, etc.) I used to use a "pass out from (self)" rule to cover these but have since switched to explicit rules so that I can have more certainty about what exactly my router is sending. -ken
Re: .iso installer file sets
On Thu, Jul 2, 2020 at 4:55 AM Mark Novem Grisola wrote: > files sets not included in "install67.iso" installer? It suppose to be > included as indicated in the documentation "/6.7/amd64/INSTALL.amd64"? > Sets are included in the ISO image, but they are not in the bsd.rd ramdisk kernel itself. When it comes time to install sets, if you accept the defaults it should mount the CD and fetch the sets from it. Or you can choose to get them over the network if you prefer. -ken
Re: late pppoe address
On Sat, Jun 6, 2020 at 11:57 AM Jan Stary wrote: > This is current/amd64 on an APU2. > The egress is XDSL pppoe(4) over vlan(4) over em(4), > > ... > > Are people having the same problem? > Are you doing something about the late ifconfig? > I have some routers that connect to DSL using pppoe(4) and yes, I have the same problem with delayed startup. For me the impact is to isc_named and openvpn, but the result is similar -- a lot of logged errors, mostly due to inability to resolve names until the pppoe link comes up. A somewhat more difficult problem is that ospfd fails to start at all under these conditions (I have it listening for routes over the vpn links, and ospfd won't start if those links are down). I don't do anything at startup to address this, because the DSL is also prone to dropping at other times for other reasons. I considered using ifstated to fix it, but found it more expedient to simply use a cron job to "rcctl start ospfd" periodically, and to ignore everything else. Ignoring everything else works because most things resolve themselves when pppoe negotiation finally completes. I am very happy that things just start working once the link comes up, and that manual intervention isn't needed. A few logged errors from software that is able to resume normal function on its own is very little burden compared to some alternatives. -ken
Re: pf table for all publicly routable ipv4 addresses
On Mon, May 4, 2020 at 4:43 PM Marko Cupać wrote: > ...so I can permit hosts on guest vlan access Internet hosts, but not > hosts on other private vlans similar to: > > block log all > pass in on $guest_vlan from $guest_vlan:network to > I suspect the best path forward here is: block log all pass in on $guest_vlan from $guest_vlan:network to ! Then make a table that's like , but also including your other vlan subnets you don't want guests to be able to reach. Each entry added to a table is implicitly an 'or'. So adding A and B to means that you get a match if you check for A, or you check for B. And adding !A and !B means that matches if it's not A, OR not B. A satisfies '!B' so that matches, B satisfies '!A' so that matches, and indeed anything else also matches. So using ! *inside* a table definition rarely does what you intend. Using ! , however, is fine and should do what you want. -ken
Re: ttyC0 floods with error messages
On Fri, Dec 13, 2019 at 8:42 AM wrote: > After boot, the following error message floods the virtual console on > ttyC0 repeatedly, rest of virtuals console stay clear somehow. Is there a > way to > treat this permanently, other than Ctrl-l everytime, or disconnecting the > mouse. > There must be some config to disable this direct dumping of errors onto > console. > > wsmouse0 at ums0 mux 0 > wsmouse0 detached > ums0 detached > uhidev2 detached > uhidev2 at uhub5 port 2 configuration 1 interface 0 "Logitech USB Optical > Mouse" rev 2.00/72.00 addr 3 > uhidev2: iclass 3/1 > ums0 at uhidev2: 3 buttons, Z dir > In my experience when the console is spammed by mouse detach and attach events, it's because the mouse is defective, usually because the cable is wearing out and developing an intermittent fault. Switch to a different mouse, even if the mouse appears to work ok, because it will probably get worse. Another reason for these messages is because you're using a KVM switch that performs the switch operation by disconnecting/reconnecting your USB devices, but I assume that isn't the cause here. Suppressing the errors is probably a bad idea, in that case how would you know your mouse is developing a fault until more serious problems arise? Better to be notified early so you have time to deal with it. -ken
Re: Turn off Swap on boot disk
On Thu, Nov 21, 2019 at 3:50 AM Sean Kamath wrote: > I have a bunch of Alix 2d13 boxes. With 6.6, I’ve found I need more swap > than the default layout on a 2G compact flash drive has. So, I got some 1G > USB thumb drives, and want to use JUST those for swap. Despite different > attempts (setting the mount_opts to xx, setting mount_opts to > “priority=1”), I can’t seem to prevent the swap on the boot disk being > added with priority = 0. > > Can I do anything to turn it off or change the priority, short of changing > the filesystem type? I wouldn't. The swap space is sometimes used for other things besides swap (like crash dumps) so why risk breaking something? Just add your thumb drive as additional swap space and leave it be. If it were me this would all be a temporary solution anyway while I acquire larger CF cards to switch to. I'm a huge fan of not getting rid of old stuff if it's still working, but when your needs outgrow your hardware, sometimes the simplest path forward is to just upgrade. The need for more swap may be related to kernel relinking -- it might be an interesting experiment to see if your existing swap space is enough with kernel relinking disabled. -ken
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: 6.6 VMs need 320Mb of ram in bhyve
On Fri, Oct 25, 2019 at 7:33 AM Noth wrote: >I just upgraded a couple of VMs to 6.6 (thanks to everyone for > another brilliant release!) that used to manage in 256Mb of RAM. They > crash at the stage the kernel loads with that amount in 6.6, and with > 288Mb the kernel loading process hangs. It takes 320Mb for them to boot > without any issues. I don't know what's changed but I thought it'd be > worth reporting. I'm using bhyve on FreeBSD 12.0. > I recently installed 6.6 under VMware ESXi 5.5 (both amd64 and i386 flavors) and they booted fine set to only 256MB (although bootup did take a long time). I can't help but wonder if it makes a difference whether you install from scratch on 256MB, or upgrade from an earlier release. Or maybe disk size makes a difference (i.e. if you are loading the kernel from a bigger disk, the boot loader needs more RAM?). My VMs are all built with 8GB disks. Either way, it's clear I need to increase the minimum RAM on my VMs, so thanks for confirming my own observation that 256MB is becoming problematic. -ken
Re: How to debug hanging machines / proc: table is full
On Tue, Jul 2, 2019 at 10:06 AM Raimo Niskanen < raimo+open...@erix.ericsson.se> wrote: > In /var/log/messages I find suspicious entries "/bsd: proc: table is full" > possibly before the machines become inresponsive, but these entries appear > many more times before that point. And after this "table is full" message > there are many syslog entries; on one machine smartd constatly complains > about > an unreadable (pending) sector and atascsi_passthru_done timeout, and on > the other the kernel complains about a probed monitor but no|invalid EDID. > In addition to Stuart's suggestion to leave top(1) running, and periodically save "ps ax" output, it might also be a good idea to start up a bunch of nested shells and just leave them running. This will reserve a bunch of process table slots, which you will be able to use via "exec", the idea being that if you can't fork new processes, you can at least use exec to replace an existing ksh process with something else. This will hopefully give you some limited ability to run a few post-mortem diagnostic commands before you run out of reserved process table slots. -ken
Re: Filesystem corruption on OpenBSD routers after power outage?
On Tue, Jun 4, 2019 at 3:34 PM Mogens Jensen wrote: > Can anyone with experience running OpenBSD routers without UPS, tell if > filesystem corruption is going to be a problem after power outages, or > if there are any officially supported ways to make the system resilient > enough to not break after a power outage? > > I'm using an mSATA disk with MLC flash in the router. > I have some OpenBSD routers without UPS protection (Soekris net6501 devices) and after using them for some years, I think it's not possible to have absolute 100% protection from filesystem corruption due to power problems, without causing other problems such as making the system overly fragile to upgrade or maintain. However, it works reasonably well to put /var/log on an MFS file system, and set up a cron job (as well as a line in /etc/rc.shutdown) to periodically rsync /var/log to another directory (so that logs will be preserved after a reboot). This works fairly well, and the system comes up properly after power failures easily over 98% of the time. Very rarely (i.e. I have seen it happen twice in a decade) you will get unlucky and have corruption anyway that requires you to run "fsck -y" manually. This is rare enough that I haven't bothered trying to automate it away. To accomplish this, I installed OpenBSD with /var/log being a separate filesystem, then edited /etc/fstab to rename /var/log to /mfs/log, and add a new entry for /var/log: swap /var/log mfs rw,nodev,nosuid,-s=128M,-P=/mfs/log 0 0 Initializing the MFS /var/log by loading from /mfs/log, combined with an rsync command in /etc/rc.shutdown, is what gives the illusion of /var/log being preserved across reboots. -ken
Re: 6.4 - Unable to boot after successfully installed
On Wed, Nov 7, 2018 at 9:29 AM Luthing wrote: > I am partitioning my disk manually like : > ~80% for /root partition > ~20% for swap Try installing again using the default disklabel slice layout. If that works that means your root file system is too big. I rarely make my root partition any larger than 512MB (128MB-256MB is typical for me). If the default slice sizes aren't large enough for you, adjust them as needed. If you need a file system with a ton of space in it, use /home for that, or make an extra slice and mount it where it makes sense (e.g. /var/mariadb if you need a big space for a database). At a minimum, you should have separate partitions for / (root), /usr, /usr/local, /var and /home. In rare circumstances I've made root file systems as large as 16GB. But a 200GB+ root is really too much. -ken
Re: Moving filesystems around
On Wed, Jul 25, 2018 at 3:32 PM Jay Hart wrote: > /var is a 6.3G partition (wd0e) using 50M of space > /usr is a 2.0G partition (wd0f) using 1.6G of space > > What would the recommended procedure to use to swap these two partitions? I wouldn't swap them exactly, rather I would make a /usr/local (and perhaps other file systems as well) so that /usr doesn't need to be very large to begin with. The general procedure I would follow is: 1. boot bsd.rd 2. mount your /dev/wd0e on /mnt 3. dump /mnt to a file (or to tape if you prefer). you may first need to mount another file system to store the dumpfile. 4. unmount /mnt, use disklabel to delete the 'e' partition from wd0, then recreate it with a smaller size 5. use newfs to build an empty file system on your new smaller wd0e partition 6. mount /dev/wd0e on /mnt again and restore the contents from the dump file you made in step 3. 7. reboot your system normally. You should then have a big chunk of unused space that you can use to make one or more new file systems for things like /usr/local, etc. If you want to shrink /usr the procedure is similar, just with 'f' instead of 'e'. Consult the man pages for dump(8) and restore(8) for more information about how to use these commands. You will probably want to use dump with the -a option, and you will probably want to use restore with the -r option. -ken
Re: How to have pf filter packets on combination of incoming and outgoing interface (for packets transiting the firewall)?
On Mon, May 7, 2018 at 12:40 PM, Martin Gignac wrote: > set state-policy if-bound > > block > > pass in on $lab01 tag from_lab01 > pass in on $lab02 tag from_lab02 > > pass in on $lab02 tagged from_lab01 > block out on $lab01 tagged from_lab02 > > Does this look like it makes sense? Is using an 'if-bound' > state-policy ill-advised? Are there any obvious problems with this > method? If so, is there a better way to achieve my goal? I imagine you meant "pass out on $lab02 tagged from_lab01". Yes, this makes sense and I don't see any reason you can't do it this way if you want to. It seems like a perfect use-case for tags. -ken
Re: state-policy floating Expectations
On Thu, Apr 26, 2018 at 2:40 PM, Daniel Melameth wrote: > The man page defines this as "States can match packets on any > interfaces." I understood this to mean that state created on one > interface would automatically create state, or allow a related match, > on another interface, but this is not the case. Simple example: > > Host A > 10.0.0.2 > > Firewall > 10.0.0.1 (hvn0) > 10.0.1.1 > > Host B > 10.0.1.2 > > /etc/pf.conf from the firewall: > block log > pass in on hvn0 > > > With the above, traffic cannot pass from A to B. With pf disabled on > the firewall, traffic passes. "floating" does not mean that "pass in" rules also count as "pass out" rules. Instead it means that a "pass in" rule for hvn0 will allow subsequent packets for that connection to be "passed in" even if they arrive on a different interface. I think this example might make it clearer what "floating" does: Firewall 10.0.0.1 (hvn0) 10.0.0.11 (hvn1) 10.0.1.1 (hvn2) /etc/pf.conf block log pass in on hvn0 pass in on hvn1 pass out on hvn2 With the above, when the first packet of a connection comes in on either hvn0 or hvn1, state will be created. If future packets switch to coming in the other interface, they will be treated as part of the already-established connection. The pass out rule is still needed to ensure that traffic that is allowed in, is also then allowed back out again. -ken
Re: httpd - serving index.html & index.php at the same time
On Tue, Apr 10, 2018 at 3:24 PM, Mischa wrote:
> Is there a way to serve both static and dynamic content, eg. index.html and
> index.php within the same server { } definition?
> I am looking for something like:
>
> server "default" {
> listen on $ext_addr port 80
> root "/htdocs"
> directory index "index.html" # not needed as it's the default
> location "/files/*" {
> root "/htdocs/files"
> directory auto index
> }
> location "^/phpapp/*" {
> root "/htdocs/phpapp"
> directory index "index.php"
> fastcgi socket "/run/php-fpm.sock"
> }
> }
This is what I have and it works fine:
server ..net {
listen on * port 80
listen on * tls port 443
tls {
key "/path/to/my/key"
certificate "/path/to/my/cert"
}
root "/ftp"
directory auto index
location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}
}
Using this I can serve index.php and index.html from the same
directory (no need to segregate php into its own subdirectory).
-ken
Re: SHA256.sig not contained in install62.iso
On Wed, Feb 21, 2018 at 4:10 AM, Jean-Michel Pouré wrote: > I know this is a little bit farfetched, pardon my ignorence, but > OpenBSD seeems vulnerable on first installation. In case of DNS > poisoning, what can stop a virus from forwarding the installer to a > false SHA256.sig and false repository? My guess would be to use > DNSSEC and a local copy of an OpenBSD repository to avoid such issue. > > Also I still don't understand the logic of not embedding SHA256.sig in > the ISO. A SHA256.sig exists, why NOT use it? This is not farfetched at all. If you obtain the ISO from an untrustworthy source, or you are misdirected to a false repository, then you cannot trust the ISO you receive. Likewise, you cannot trust any SHA256.sig file you receive. So, after you download SHA256.sig, you need a way to confirm that your copy of SHA256.sig is genuine, then once that's done you can verify whether your ISO is valid. This is what the signify tool does. It is small enough that you should be able to build it yourself on a machine you trust, and the OpenBSD pubkey that you need for SHA256.sig verification is small enough that you can key it in by hand if needed, and also small enough that you can visually confirm you have the correct key by comparing it with one from a trusted source (an original OpenBSD CD-ROM, a T-shirt, a picture you took during an OpenBSD presentation, etc.) The SHA256.sig that already exists can't be included in the ISO because it contains the signature of the ISO itself. So imagine you've made an ISO image, then you get the SHA256 hash of it, make and sign a SHA256.sig file`, but then you need to take this new file you've just created and put it into the ISO, which will cause the ISO's hash to change, invalidating the SHA256.sig you just created. So you would need to have two versions of SHA256.sig, one version that contains hashes for the ISO file (and also other 'installer' files like miniroot.fs and installNN.fs), and another SHA256.sig that contains hashes for the base sets (baseNN.tgz, compNN.tgz, gamesNN.tgz, etc.) and you would put the second SHA256.sig into the ISO, then create the first SHA256.sig later. For this to work (two SHA256.sig files with the same name but different content) you need to have two directories on all the mirrors, one for the file system images and another for bsd.rd and the sets, or you have to be ok with there being a file inside the ISO that doesn't match the same-named file available from the mirrors. In the end, since any SHA256.sig inside the ISO can't be trusted anyway unless you verified the ISO before you booted it, might as well just leave it out. The only time it's actually useful is if you are installing by booting a verified bsd.rd directly, and downloading the sets during installation (in which case the sets need to be verified after download). I suspect that it's really only for the benefit of people installing this way that the installer verifies SHA256.sig signatures at all. -ken
Re: signify-openbsd to crypt'ly verify install62.iso in linux
On Fri, Feb 9, 2018 at 4:44 PM, Kevin Chadwick wrote: > On Fri, 09 Feb 2018 16:11:01 -0500 >> but I can't for the life of me figure out how to cryptographically >> verify the legitimacy of install62.iso with SHA256.sig. > > I've never done it on linux however try > > signify -C -p /etc/signify/openbsd-62-base.pub -x SHA256.sig > > https://man.openbsd.org/signify The next question of course will be, how can you be sure that your copy of /etc/signify/openbsd-62-base.pub is legitimate? Someone could have tampered with that file as easily as they could have tampered with SHA256.sig. You can go to https://www.openbsd.org/62.html to get the 6.2 signify keys, but how sure can you be that the site hasn't been compromised? Or that the site you see in your browser is even the real one? At some point you need to convince yourself that you have a good key. The keys have been published in various places, and the last several CD releases (from 5.5 or so until CD distribution stopped) had the signify keys actually printed on the CD labels. Each release of OpenBSD includes keys for the next release, so once you have a key you trust you can use that to verify that version, then use the key in that version to verify the next version, and so on. This paper provides some good background about why signify rather than https or gpg: http://www.openbsd.org/papers/bsdcan-signify.html -ken
Re: missing /var/db
On Thu, Feb 1, 2018 at 9:28 AM, Ultramedia Libertad wrote: > the disk with the partition /var to dead then we have replaced it, but > accidentally and stupidly I lost some sections of /var as /var/db so now I > try to verify the install and uninstall packages but I can not go away > /var/db/pkg This is a lesson that many people learn the hard way -- always have backups. If you had a full backup of /var you would not have this problem now (this doesn't help you now, I say this only for others reading this message). The simplest thing to do is to simply create the /var/db directory and see if the package tools will automatically recreate the /var/db/pkg file. But this solves only one problem, who knows how many other things are broken due to missing /var files? Might as well do the job right and try to fix everything now. So the best path forward if you have no complete backup of /var is to get a fully populated /var partition from somewhere else, back it up, then restore it on this system. One way to do this is to use the copy of /var that is in the OpenBSD installer: back up everything, completely reinstall OpenBSD on this system from scratch (which will fully populate /var), then restore the files you care about. Another option (you might prefer this) is to do a fresh install of OpenBSD (same version, same architecture, probably amd64 or i386 in your case) onto a small disk (a USB thumb drive will do) then use tar to make a backup of /var (cd /var; tar cfz /home/var-backup.tar.gz .), then use that to restore the default contents of /var (mkdir /var/restore; cd /var/restore; tar xpfz /some/path/var-backup.tar.gz). You can then start moving things you need from /var/restore to var (for example mv /var/restore/db /var/db). I would not use dump/restore for this kind of task because restore works best restoring onto a blank file system, but your 3TB /var probably already has other files in it already. You could also extract the missing /var files directly from the installation sets but I don't advise going down this path unless you really know what you are doing. It is certainly not something I would feel comfortable instructing others to do. If I recall correctly the installation sets are just tar files. -ken
Re: "uhub1: device problem, disabling port 1" on Zenbook
On Sun, Jan 28, 2018 at 4:23 AM, Maximilian Pichler wrote: > I'm trying to install OpenBSD 6.2 on a Zenbook (UX390UA) but it is > unable to find the installer USB key (after booting from it). The key > is connected via the USB-A/C adapter/hub that comes with the laptop. > The same hardware works fine under Linux. > $ ls /dev/*sd1* > ls: /dev/*sd1*: No such file or directory the RAMDISK kernel is extremely space-constrained, so its /dev directory is not fully populated. When you reach the "(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?" prompt, enter S then type the following commands to create the sd1 device entries: # cd /etc # ./MAKEDEV sd1 # exit You will then be returned to the installer and you should be able to proceed normally. -ken
Re: IPsec help: too much NAT!
When faced with an ISP modem/router, I generally try to switch it to bridge mode and move the PPPoE / DHCP client formerly handled by the ISP hardware to the OpenBSD system instead. This rather simplifies things if you can make it work because then your OpenBSD system has the Internet-facing address and you remove a layer of NAT. It's unclear to me whether you are stuck with the ISP hardware (but can change it to bridged if you like) or if you are also stuck with it being configured as a NAT router as well so I don't know if this is something you can do. -ken On Thu, Jan 25, 2018 at 6:01 PM, Stuart Henderson wrote: > On 2018-01-25, Lyndon Nerenberg wrote: >> I have an IPsec conundrum I'm trying to solve. Yes, the scenario >> is somewhat absurd; it's also the problem I've been taksed with >> solving, so spare the peanut gallery comments, okay? >> >> >> NET-P GW-Q <-> internet <-> GW-H GW-V NET-V >> >> NET-P is 10.0.2.0/24 >> NET-V is 10.0.11.0/24 >> >> GW-Q is an OpenBSD host with fixed addresses 10.0.2.1 (inside) and >> 1.2.3.4 (internet). >> >> GW-H is some random ISP cable/DSL modem that NATs everything behind >> it, with a random external address. (I.e., assume DHCP on the >> "internet" side.) >> >> GW-V is an OpenBSD host. It has a variable upstream address obtained >> from the back end of GW-H (DHCP). On the other side, GW-V presents >> 10.0.11.1 to NET-V. >> >> The goal here is to establish an IPsec tunnel that links NET-P and >> NET-V together, in the face of all the other nonsense in between. >> >> In the schematic above, '' represents a NAT translation point. >> '<->' is a regular router interconnect. >> >> I have tried setting up an IKEv2 passive connection from GW-V to >> GW-Q (connections in the other direction are impossible), but I'll >> be damned if I can figure out how to specify the SA associations >> and ESP flows on GW-V, given the lack of fixed addresses on the >> upstream sides of GW-V and GW-H. (Or in the other direction, for >> that matter.) >> >> Is there any hope this can possibly work? > > That's a pretty standard setup. I don't have an iked one handy to crib > from but ipsec.conf/isakmpd looks like this: > > - natted side > > ike dynamic esp from $natted_side_net/27 to $other_net/21 \ > peer $remote_external_IP \ > main auth hmac-sha1 enc aes group modp3072 \ > quick enc aes-128-gcm group modp3072 srcid myname > > - side with real ip > > ike passive esp from $other_net/21 to any \ > main auth hmac-sha1 enc aes group modp3072 \ > quick enc aes-128-gcm group modp3072 srcid othername > > iked should be similar, use "ikev2 active" on the natted side, "ikev2 > passive" on the static-ip side. > > Watch out for "nat helpers" on GW-H that try to fix things up but actually > break them but there aren't usually problems these days. > >
Re: Simplifying pf-rules
On Thu, Jan 4, 2018 at 8:09 AM, Jon S wrote:
> This led to my first experieces with pf. After some work I came up with
> whats below. It works as I want it to work, but I wonder if there is a way
> to create a rule where incomming traffic to the internal NIC (re0) is
> passed if it is targeted for em0 (external, internet NIC)? The current
> solution would require an update of the "pass in on re0 to
> !re0:network"-rule if another NIC is added (lets say a DMZ).
>
> [ruleset omitted]
For years I used a vaguely similar ruleset on my own router; similar
in the sense that it used "pass out all" and relied only on filtering
inbound traffic.
But over time I've decided that it's better to block both inbound and
outbound by default, then explicitly allow traffic in 3 categories:
1. traffic to this router as the final destination (for services
running on the router)
2. traffic to be forwarded (with NAT if needed)
3. traffic that originates from this router
#3 is especially important if the router is also running other
services which may make announcements on the network. If you are
running Samba for example you probably don't want to send
announcements to the Internet. Yes, this means you need to know
explicitly what your services are doing so you know what to enable.
On the plus side it means nothing gets sent to the Internet simply
because you didn't know you needed to turn it off.
To differentiate between #1 and #2 I use tags to mark packets as
ACCEPT or FORWARD. Only the packets tagged FORWARD are allowed to
pass out. Inbound packets start with a TBD tag that basically means
"not yet tagged" and ensures that once a rule sets an ACCEPT or
FORWARD tag, other rules don't then try to re-tag it.
Also, I try to avoid using ! anywhere. It is too easy to make
mistakes with it, and configuration mistakes are the #1 reason
unwanted traffic will get through your firewall.
A very stripped down subset of my ruleset follows, showing the
essentials. em0 is my internal interface, em1 is my 'guest' interface
(that friends can use for their WiFi when they visit) and em2 connects
to my Internet cable modem (I don't use variable name substitutions
for unrelated reasons, but you may want to do so anyway). I have
included em1 because it's very similar to a DMZ network. I am running
several services on my router so I've also included the DNS and
ftp-proxy rules because they are good examples. Note that I make
extensive use of "quick" to give "first matching rule wins" behavior.
I think this is easier to understand.
# pf.conf - PF configuration file
# tables
table const { 10/8, 172.16/12, 192.168/16 }
# by default, block all traffic not explicitly allowed
block in log all tag TBD
block out log all
# ACCEPT - traffic that should be accepted by this router (not forwarded)
# accept ping requests
pass in log quick on em0 inet proto icmp from em0:network to (self)
icmp-type echoreq tagged TBD tag ACCEPT
pass in log quick on em1 inet proto icmp from em1:network to em1
icmp-type echoreq tagged TBD tag ACCEPT
# accept DNS requests
pass in log quick on em0 inet proto { udp tcp } to (self) port domain
tagged TBD tag ACCEPT
pass in log quick on em1 inet proto { udp tcp } from em1:network to
em1 port domain tagged TBD tag ACCEPT
# accept SSH connections
pass in log quick on em0 inet proto tcp from em0:network to (self)
port ssh tagged TBD tag ACCEPT
pass in log quick on em1 inet proto tcp from em1:network to em1 port
ssh tagged TBD tag ACCEPT
# FORWARD / Inbound - traffic that should be forwarded by this router
# block non-Internet traffic from public (guest) network
block in log quick on em1 to tagged TBD
# pass internal FTP traffic
pass in log quick on em0 inet proto tcp from em0:network to 192.168/18
port ftp tagged TBD tag FORWARD
# proxy external FTP traffic
pass in log quick on em0 inet proto tcp from em0:network to port ftp
divert-to 127.0.0.1 port 8021 tagged TBD tag ACCEPT
pass in log quick on em1 inet proto tcp from em1:network to port ftp
divert-to 127.0.0.1 port 8021 tagged TBD tag ACCEPT
anchor "ftp-proxy/*"
# default forwarding rules for traffic from private network
pass in log quick on em0 from em0:network to 192.168/18 tagged TBD tag FORWARD
pass in log quick on em0 from em0:network modulate state tagged TBD tag FORWARD
# default forwarding rules for traffic from public (guest) network
pass in log quick on em1 from em1:network to em1:network tagged TBD tag FORWARD
pass in log quick on em1 from em1:network modulate state tagged TBD tag FORWARD
# game server
pass in log quick on em2 inet proto udp to (em2) port 27016 rdr-to
192.168.24.50 tagged TBD tag FORWARD
# FORWARD / Outbound
# forward internal traffic
pass out log quick on em0 tagged FORWARD
pass out log quick on em1 tagged FORWARD
# block unroutable external traffic
block out log quick on em2 to tagged FORWARD
# forward external traffic
pass out log quick on em2 nat-to (em2) tagged FORWARD
# Outbound - traffic that may originate from this
Re: public key-only accounts
On Tue, Nov 21, 2017 at 1:50 AM, Jan Stary wrote: > Running security(8): > > Checking the /etc/master.passwd file: > Login maxa is off but still has a valid shell and alternate access files in >home directory are still readable. > > > According to master.passwd(5) > > login accounts not allowing password authentication but allowing > other authentication methods, for example public key authentication, > conventionally have 13 asterisks in the password field. > > but adduser did not put 13 asterisks in the password field (just '*') > and security(8)'s check_passwd() seems to have no notion of > '13 asterisks in the password field' - the login is just considered 'off' > if $pwd !~ /^\$[0-9a-f]+\$/ > > Is the info in master.passwd(5) still valid? > Should adduser put '*' as the passwd for such accounts? > (I do see accounts with 13 asterisks for passwd, e.g. _postgresql.) The 13 asterisks trick does work. Look at security(8) again, but one line higher: length $pwd != 13 && It does make sense to me that adduser(8) should put in 13 asterisks instead of 1 but until now I have remained silent because I did not have any diff to submit. In the meantime I have been using vipw(8) to manually set the 13 asterisks on the appropriate accounts. In my case I am using such accounts for remote backups via SSH, and I had the same issue with security notifications. I did not want to just ignore the messages because that leads to bad habits. -ken
Re: I'm stuck with pf - can someone with some experience check my rules please? Thanks
On Thu, Oct 12, 2017 at 7:48 AM, tec...@protonmail.com wrote: > I have been reading through the Book of PF (3rd edition) and other resources > on the web (FAQ), so far so good but I'm hitting some roadblocks. This > router I have built is also acting as a client to an external VPN server, it > works and my client is getting a connection just fine. The problem is that > whenever OpenVPN is active I cannot SSH in from a specific subnet - my pf > rules aren't right. Is there some obvious issue with my rules standing out > to you? I appreciate you looking, thanks. > > Topology: > [pfSense Router: 192.168.1.1] (wifi lan subnet 192.168.2.0/24 / ethernet lan > subnet 192.168.1.0/24) -- Unmanaged Switch -- [OpenBSD router : > 192.168.1.100] (ethernet lan subnet 10.0.0.0/24) > > What doesn't work: > pfSense clients on the wifi lan subnet SSH'ing in to the OpenBSD router > (when OpenVPN is active on the OpenBSD router) I suspect that you have an address conflict between your WiFi network and the networks that are reachable via OpenVPN. I'm guessing your VPN service is either giving you a 192.168.2.x address for your OpenVPN client, or they are pushing a route to their own 192.168.2.0 network that takes precedence over your own. The output of "netstat -nrf inet" (while OpenVPN is active) will help to identify the problem. -ken
Re: permission denied local nfs mount
On Fri, Jul 28, 2017 at 7:36 PM, Allan Streib wrote: > $ cat /etc/exports > /home/astreib/work/new-site.org -ro -network=127.0.0.1 > > Everyhing works if I remove the "-network=" from /etc/exports, i.e.: > > /home/astreib/work/new-site.org -ro 127.0.0.1 > > I don't really understand why? If you don't specify -network, then 127.0.0.1 is treated as the address (or name) of a specific host. Since you are going to be mounting this via 127.0.0.1, that counts as a host address and everything works. If you do specify -network, then 127.0.0.1 is treated as a network number, and the default netmask would be 255.0.0.0. I don't know why that's not working, but (a) I always specify -mask whenever I use -network, and (b) I always ensure that the host portion of the network number is all zeros. So if I were to do it I would use: /home/astreib/work/new-site.org -ro -network 127.0.0.0 -mask 255.0.0.0 (I would use 255.0.0.0 as the mask simply because that's the mask the actual loopback interface is using, but I don't think it actually matters as far as /etc/exports is concerned -- if you want to use an unusual mask to allow access to a subset of a network then as far as I know you should be able to). Unless you are binding multiple addresses on your loopback interface, I would just use 127.0.0.1 without -network or -mask and be done with it. Why open up the mount to an entire network when you really just need to open it up to a single host (yourself)? This is what I do in a similar situation (serving both ftpd and httpd from the same directory): relevant line from /etc/exports: /nfs/archive/dist/OpenBSD -maproot=root -ro 127.0.0.1 relevant line from /etc/fstab: localhost:/nfs/archive/dist/OpenBSD /var/www/ftp/pub/OpenBSD nfs ro,nodev,nosuid 0 0 Works fine for me. -ken
Re: Split zone DNS?
On Fri, Jul 28, 2017 at 9:58 AM, Steve Williams wrote: > I would like to run a local resolver on my internal network that will > resolve all my hosts on my local network to IP addresses on my local > network(s) rather than resolving to their public IP addresses. > > What is the best tool to accomplish this these days? Is NSD the "modern" > tool to be using on OpenBSD? > > Are there any hooks for dhcpd to update records? I have found the readily available documentation unclear on how to handle dynamic DNS updates when DHCP is in use. The advice I've seen has basically been either to not bother, or to have DHCP assign fixed addresses (i.e. don't do dynamic DNS). It's not totally clear whether it's even possible using nsd/unbound and the base dhcpd, but what I've seen indicates that it is not. So, what I am doing instead is I'm using isc-dhcp-server and isc-bind (from packages). Note that I provide DNS/DHCP service on my internal network only (I do not provide any DNS name resolution of any kind on my Internet-facing interfaces) so it's not really "split-horizon". If I were to provide split-horizon DNS I would probably use two separate machines, one providing internal service (using isc-dhcp-server and isc-bind) and another providing external service (using nsd). -ken
Re: Question about pf tables and limitation of addresses 0.0.0.0/0 or 0/0
On Thu, Jul 27, 2017 at 12:52 PM, Donald Clark Jackson
wrote:
> table const { !10/8 !172.16/12 !192.168/16 0/0 }
> guest_hq_if = "em3"
> guest_hq_net = $guest_hq_if:network
> pass log (matches) from $guest_hq_net to keep state
>
> match out log (matches) on $external_if inet from $guest_hq_net nat-to
> ($external_if)
I'm not sure this ruleset is doing what you think it's doing. Try
running the following command to verify that your table
contains what you think it should:
# pfctl -t public -T show
Putting aside for the moment whether 0/0 works or not, I think you
have another problem with the ! marks. To explain the problem, let's
pretend the entire Internet consists of just 3 class A networks: 1/8,
2/8 and 3/8. So what does { !1/8 !2/8 } mean? It's a table
containing all the addresses not in 1/8 (i.e. 2/8 3/8), plus all the
addresses not in 2/8 (i.e. 1/8 3/8):
{ 2/8 3/8 1/8 3/8 } simplifies to { 1/8 2/8 3/8 }, which matches
everything and is probably not what you intended.
I don't think you can even use ! in a table, even though "pfctl -nf"
doesn't appear to complain about it at all. When I try it in
5.9/amd64 the tables end up being not defined.
If you want to provide an Internet-only guest network, I recommend you
try something like this:
table { 10/8, 172.16/12, 192.168/16 }
guest_if = "em3"
ext_if = "em0" # or whatever your egress interface is
pass in log on $guest_if from $guest_if:network to any
block in log quick on $guest_if to $guest_if # note 1
block out log quick on $ext_if from $guest_if:network to # note 2
pass out log on $ext_if from $guest_if:network nat-to ($ext_if)
This lets guest traffic into the router, then relies on your routing
table to decide which outbound interface the traffic should then be
forwarded to. Traffic to the Internet (going out through $ext_if) is
passed with an explicit "pass out" rule (and NAT is applied at the
same time). Traffic attempting to reach your other internal networks
is not forwarded because there is no "pass out" rule on any other
interface allowing it.
note 1: Connections *to* your router rather than *through* your router
are dropped, to prevent guests from trying to ssh into your router.
If you want to allow guests to connect to your router for certain
services (e.g. dns) then you will want to be more selective.
note 2: Internet traffic to "unrouteable" Internet addresses is
dropped. Note that this rule explicitly applies only to traffic "from
$guest_if:network" because other outbound traffic might legitimately
need to send to such an address. For example, some ISP's will provide
a 10/8 address as your default route, and blocking 10/8
unconditionally will prevent you from doing things like pinging that
router.
As you have discovered, once you have more than two networks (internal
and external) things can start to get complicated, which means the
opportunity to make mistakes goes up dramatically. What I do to make
things clearer (and to reduce the impact of mistakes) is to use tags
to categorize traffic:
### BEGIN ###
private = "em0"
guest = "em1"
inet = "em2"
table const { 10/8, 172.16/12, 192.168/16 }
# Inbound traffic is blocked by default and tagged TBD until it can be
categorized
block in log all tag TBD
# Inbound / ACCEPT - traffic that should be accepted by this router
(not forwarded)
pass in log quick on $private inet proto tcp from $private:network to
$private port ssh tagged TBD tag ACCEPT
pass in log quick on $private inet proto icmp from $private:network to
(self) icmp-type echoreq tagged TBD tag ACCEPT
pass in log quick on $guest inet proto icmp from $guest:network to
(self) icmp-type echoreq tagged TBD tag ACCEPT
pass in log quick on $private inet proto {udp tcp} from
$private:network to em0 port {domain ntp} tagged TBD tag ACCEPT
pass in log quick on $guest inet proto {udp tcp} from $guest:network
to $guest port {domain ntp} tagged TBD tag ACCEPT
pass in log quick on $private inet proto tcp from $private:network to
port ftp divert-to 127.0.0.1 port 8021 tagged TBD tag ACCEPT
pass in log quick on $guest inet proto tcp from $guest:network to port
ftp divert-to 127.0.0.1 port 8021 tagged TBD tag ACCEPT
anchor "ftp-proxy/*"
# Inbound / FORWARD - traffic that should be forwarded by this router
pass in log quick on $private from $private:network tagged TBD tag FORWARD
block in log quick on $guest from $guest:network to $private:network
tagged TBD tag BLOCK
pass in log quick on $guest from $guest:network tagged TBD tag FORWARD
# Outbound / FORWARD
block out log all # by default block all outbound traffic not explicitly allowed
pass out log quick on $private tagged FORWARD
pass out log quick on $guest tagged FORWARD
block out log quick on $inet to tag BLOCK
pass out log quick on $inet nat-to ($inet) tagged FORWARD
# Outbound - traffic that may originate from this router (even this is
blocked by default)
pass out log quick on $inet inet proto udp from ($inet) port bootpc to
any port bootps # ISP DHCP service
p
Re: OpenBSD NFS: Windows 10 writes wrong uid
On Mon, Jun 12, 2017 at 12:58 PM, Rupert Gallagher wrote: > On problem 2, > > if a user has group write permission on a folder, it has permission to write > its own files and those of same group membership in that folder, provided the > group permission is set on the file by its owner. If a file belongs to me and > I deny write permission to group and other, then nobody can write my file. > File creation and destruction are forms of writing. This is what I am used to > see. The ability of a windows nfs user to delete a file for which it has no > write permission is a security This may be what you are used to seeing on other systems, but this is not how Unix works. It may help you understand the situation if you consider that in Unix, a directory is nothing more than a list of names associated with inode numbers. Creating a file is actually a two-step process under the hood: first a new inode is allocated for the file, then a name is added to some directory, linking to the new inode. You can then add as many additional links to that same file as you like, in that same directory or in other directories. A file can therefore have many names and be found in many folders within the same file system. Permissions to read or write the file content (the inode) are based on the file permissions, and because the file permissions are for the inode (not the name) those permissions always apply no matter which name you use (you cannot have one name that allows writing, and another name that's read-only). If you want to remove one of the (possibly many) names for a file, you need write permission on the directory containing that name, because what you are doing is removing a link that connects that name to the inode. It does not matter whether you have permissions to read or write the content of the file because you are not touching the file -- other links to that same file remain undisturbed unless you remove those as well (assuming you have the directory permissions required). When the last link to a file is removed, the inode is deallocated and the file's data blocks are freed. The rules in Unix are then: 1. if you want to allow users to create or delete file names in a directory, give them write permission to the directory. 2. if you want to allow users to modify file contents, give them write permissions to the file. These rules are very simple, but they may not be the rules you are used to, and they are likely not the rules you want. But if you want different rules then you must choose a different system. If you want to use this system you need to apply these rules. -ken P.S. 4294967294 is the NFS 'nobody' uid -2 (expressed as an unsigned number), which is similar to but not the same as the 'nobody' uid -1. If the files you create end up owned by that uid, it means your client (Windows 10) is asserting that your uid is 0 (root). It is an NFS convention that being root on the client should not mean that you get root access to files on the server, so a client claiming to be root gets no permissions by default rather than all permissions. The 'map' and 'mapall' options override this behavior.
Re: Advice on migration to OpenBSD
On Sat, May 13, 2017 at 9:02 PM, Kim Blackwood wrote: > problem with the abovesetup. However, migrating to OpenBSD on my personal > laptop and desktopI suspect will give me some problems mounting both > Samba shares andexternal drives. We could change the file systems on the > external drives to say EXT2 ifthat's a "good" idea or NTFS if that's > better supported, I don't know.Both read and write access is needed. The > Samba boxes aren't going to change as to many people use those. Iremember > something about sharity-light in the past, but that was notvery good back > then. How do you guys do it? Is it even doable running only OpenBSD on > myboxes in such an environment? Thank you for your time. Kind regards, Kim What I do in this situation is dual-mount the volumes using both Samba and NFS. The systems that work better with SMB (e.g. Windows) can then use Samba, while the system that work better with NFS (OpenBSD) can use that. Of course for this to work your servers need to be able to support both NFS and Samba. I use OpenBSD as a file server and it can do this without any difficulty. -ken
Re: Does OpenBSD's pf prevents Hole punching?
On Sat, Apr 8, 2017 at 4:39 AM, Marina Ala wrote: > I heard that OpenBSD's pf can prevent Hole punching: > Is it true? I just cannot google on it, but if someone would answer this > thread then the world can google for it from that point :D PF doesn't prevent hole punching by itself, but depending on how you have it configured, it can make hole punching difficult or impossible. Of course a ruleset that blocks everything (e.g. "block all quick") will block everything, including hole punching requests. This can be useful if you want to allow Internet access for a specific machine, but block Internet access for all other machines. But if you allow your users to make direct outbound connections (e.g. for web browsing or playing online games) then users in your network can use those outbound connections to initiate hole punching (outbound) and there's not much you can do to stop it without resorting to IP address filtering. If you are trying to block inbound hole punching (or peer-to-peer hole punching) PF naturally makes this hard due to port randomization (the external party cannot reliably predict which port on your side they should try to connect to). If you want to allow peer-to-peer hole punching you can make it easier by using the static-port option described in the pf.conf(5) man page but this can cause problems if you have multiple internal hosts all trying to send from the same port numbers. Despite PF making hole punching harder, if the other side makes things sufficiently easier (no NAT, or no address-specific port mapping) then peer-to-peer hole punching might succeed anyway. If you are trying to block your users from running applications that use hole punching, you may not be able to do it unless you block everything. Blocking all direct user traffic and having them use a web proxy would help, but still wouldn't block applications that can masquerade as a web server. -ken
NFS uid/gid remapping for root
The man page for exports(5) claims that remote accesses by root will be mapped to uid/gid -2:-2 unless overridden via the -maproot or -mapall options. But if root creates a file the result is clearly different: # touch test # ls -alF total 32 drwxrwxrwx 2 ken 999 512 Apr 1 00:05 ./ drwxrwxr-x 12 root999 512 Apr 1 00:05 ../ -rw-r--r-- 1 4294967294 9990 Apr 1 00:07 test # The problem is obvious: despite the claims of the man page, there is no such uid/gid as -2:-2. This diff fixes the problem: Index: master.passwd === RCS file: /cvs/src/etc/master.passwd,v retrieving revision 1.88 diff -u -p -r1.88 master.passwd --- master.passwd 5 Mar 2016 12:31:38 - 1.88 +++ master.passwd 1 Apr 2017 04:12:19 - @@ -58,3 +58,4 @@ _tftp_proxy:*:108:108::0:0:tftp proxy da _ftp_proxy:*:109:109::0:0:ftp proxy daemon:/nonexistent:/sbin/nologin _sndiop:*:110:110::0:0:sndio privileged user:/var/empty:/sbin/nologin nobody:*:32767:32767::0:0:Unprivileged user:/nonexistent:/sbin/nologin +-2:*:4294967294:4294967294::0:0:Unprivileged NFS user:/nonexistent:/sbin/nologin Index: group === RCS file: /cvs/src/etc/group,v retrieving revision 1.79 diff -u -p -r1.79 group --- group 5 Mar 2016 12:31:38 - 1.79 +++ group 1 Apr 2017 04:12:19 - @@ -77,3 +77,4 @@ _sndiop:*:110: dialer:*:117: nogroup:*:32766: nobody:*:32767: +-2:*:4294967294: Happy April 1st! -ken
Re: OpenBSD's HTTPD - I can't figure out how to disable the chroot
On Sun, Feb 12, 2017 at 6:03 PM, wrote: > I have a special use case for the HTTPD server, I would like to disable > the chroot but can't seem to get it working correctly. While I can't help you with your httpd chroot issue, I can suggest that if you need to access a part of the filesystem outside of /var/www, you can NFS mount it from yourself. For example, suppose you have a directory /nfs/archive/dist/OpenBSD, and you want to serve it via httpd. You can do something like this: 1. add a line to /etc/exports: /nfs/archive/dist/OpenBSD -ro 127.0.0.1 2. start nfsd: # rcctl start nfsd 3. remount your data under /var/www: # mkdir -p /var/www/htdocs/pub/OpenBSD # mount -r 127.0.0.1:/nfs/archive/dist/OpenBSD /var/www/htdocs/pub/OpenBSD At this point you should be able to chroot to /var/www, and still be able to access files under /htdocs/pub/OpenBSD. This may not be the prettiest way to achieve your goal but it's simple and it works for ftpd. I assume it would work just as well for httpd. -ken
Re: Non-free firmware without asking the user
On Sat, Jan 7, 2017 at 11:35 AM, Stefan Sperling wrote: > On Sat, Jan 07, 2017 at 10:16:39AM -0500, Kenneth Gober wrote: >> The difference is, closed source firmware runs on the device itself >> and if it's buggy, generally the most it will do is make the device >> appear to be non-functional or unreliable. > > If a PCI device has unrestricted DMA access, as is the case in most laptops > and PCs today as far as I know (no IOMMU), it can do a lot of damage. > In this case firmware running on devices essentially has root privileges > on the OS since the firmware could modify arbitrary memory. > > It all boils down to whether you trust hardware vendors to not use their > powers against you. There is nothing an OS kernel could do to prevent > attacks at this level. Quite so. I actually had a few sentences on this but I deleted them due to it straying too far off topic. But the end result as you say is, if you don't trust the hardware don't use it. An OpenBSD firmware prompt is not going to make you safe from malicious hardware. -ken
Re: Non-free firmware without asking the user
On Fri, Jan 6, 2017 at 4:45 PM, Martin Hanson wrote: > Yes, it can be argued that since we cannot get any open hardware at all it doesn't matter whether the firmware is located on a ROM or if it's installed by the kernel, but if we use that logic we might as well just use whatever binary driver blob the vendors make for everything, right? > > If no, then why not, what's the difference between running closed source firmware and closed source drivers? The difference is, closed source firmware runs on the device itself and if it's buggy, generally the most it will do is make the device appear to be non-functional or unreliable. An open-source driver can detect a device malfunction and handle it (or if it doesn't it can potentially be modified to do so). A closed source driver runs as part of the kernel and has ready access to all parts of the kernel, and even user memory. A buggy driver could merely cause the device to appear to work improperly (if you're lucky), or it could corrupt kernel memory in subtle ways causing unrelated parts of the system to fail after an indeterminate amount of time has passed, and in such a situation there is little you can do to reasonably fix the problem without driver source except to remove the driver. Clearly the second situation (closed driver) is the worse one to be in, and from a practical perspective, the first one is nearly unavoidable nowadays. Even my mouse has closed-source firmware in it and there is little point in putting an extra prompt in the installer that shows up depending on whether my firmware is pre-installed in a ROM or not. Because let's be clear here, that's what that prompt signaled. Not that your device may be using non-free firmware, but rather that your device doesn't store its firmware on-board but needs to have it loaded. Maybe someday we will have virtual kernels running in user mode jails where we can safely run closed driver blobs without risking the rest of the kernel, and if that ever happens then maybe closed driver blobs might be OK. If you absolutely refuse to use non-free hardware then the prompt will not save you -- all a vendor has to do to evade the prompt is put their firmware in ROM. Your only solution here is dligent research and careful choice of vendors, and if you're doing that then the prompt isn't needed anyway. So the prompt was ignored by the people who don't care, and ineffective for the people who do care, and therefore useless. -ken
Re: Recommendation for firewall appliance running of and OpenBSD
On Thu, Nov 24, 2016 at 3:15 PM, Tito Mari Francis H. Escaño wrote: > Hi everyone, > Can somebody please recommend me a firewall appliance that can run OpenBSD and > pf, and can be upgradeable to the latest version? It would be a great plus if > the appliance can also be configured as part of CARP firewall group. pfSense > with FreeBSD doesn't cut it :) I have a few Soekris net6501 appliances that mostly work fine (they sometimes fail to boot due to some mSATA issue, but pressing the reset button generally fixes it). http://soekris.com/products/net6501-1.html A good-quality business PC with a multi-port Ethernet card also works fine as a router. My 'main' router is currently a Dell Optiplex 755 SFF with a low-profile 4-port Intel Gigabit adapter added to it. These are easy and cheap to find refurbished/used, but are probably not a good option if you require something with a serial console. -ken
Re: strange behaviour with route-to, default route, and ping -I
On Mon, Nov 21, 2016 at 12:10 PM, Stefan Sperling wrote: > On Mon, Nov 21, 2016 at 10:43:17AM -0500, Kenneth Gober wrote: >> I get the impression that route-to is applied when a packet enters the >> router, >> e.g. as part of a "pass in" rule, and that it is used to forcibly direct the >> packet to a particular interface for "pass out" rather than relying on the >> default routing table for the entry interface. >> >> This means that if the "pass out" rule is the first time you are seeing the >> packet (i.e. because it originated from the router itself) then the routing >> decision has already been made and it is now too late to route again. > > route-to takes effect when a state is created by a matched rule. > It is possible to use route-to on 'pass out' rules (at least, over here, > it works :) Prompted by Stefan, I made some time to test this myself and I can confirm that this works. I started with this rule in pf.conf: pass in log quick on em0 from em0:network to 8.8.8.8 route-to pppoe0 tagged TBD tag FORWARD And "ping 8.8.8.8" from the internal network got redirected to pppoe0 (default route is em2) but the same command issued at the router did not get redirected. I do not show the pass out rule here but I have a later one that will pass out (with NAT) anything tagged FORWARD. Adding this rule as well: pass out log quick on em2 to 8.8.8.8 route-to pppoe0 Caused "ping 8.8.8.8" originating from the router itself to be redirected just like the corresponding internal traffic. -ken
Re: Making motd great again
On Sun, Nov 20, 2016 at 1:22 AM, Gareth Nelson wrote: > Filling the terminal isn't really a major issue though is it? > Terminals do scroll after all Framebuffer consoles don't. Although they're a bit larger than 80x24 so it matters less. If a novice user doesn't know about the "help" command, it is also likely that they will either (a) not know that a framebuffer console has no scrollback buffer, or (b) not know the magic keystrokes to scroll a text-mode console (on a PC, it's not simply "PgUp"). I do like the idea of making MOTD shorter. -ken
Re: strange behaviour with route-to, default route, and ping -I
On Mon, Nov 21, 2016 at 4:21 AM, Comète wrote: > I use route-to in my pf.conf to route packets from my LAN through 4 > non-equal WAN links (multipath routing is disabled). It works nicely, but if I > try to send pings from the firewall itself through a specific WAN interface > with ping -I or traceroute -s commands, it's always the default route on the > FW that is used. I get the impression that route-to is applied when a packet enters the router, e.g. as part of a "pass in" rule, and that it is used to forcibly direct the packet to a particular interface for "pass out" rather than relying on the default routing table for the entry interface. This means that if the "pass out" rule is the first time you are seeing the packet (i.e. because it originated from the router itself) then the routing decision has already been made and it is now too late to route again. It is my understanding that you can set up special routing tables that have different default routes (see rdomain(4)), then use route(8) to run commands, using -T to specify which route table to use. I have never tried this myself but the man pages should have enough information to get you going. -ken
Re: strict separation base system and third party software
On Sat, Oct 29, 2016 at 4:21 PM, Mihai Popescu wrote: > Folks, since we are at it, does anyone knows why 'OpenBSD' is spelled > like that and not 'openbsd' . I was ponder that for a time, because I > know you all hate camelCase notation. In this context, "OpenBSD" is a proper noun, and therefore follows rules appropriate for such names. See also "OpenSSH", etc. camel case (and other such conventions) is used for variable names, function names, and sometimes program names. "identifier names" is the technical term for the kinds of names such rules generally apply to. Do not blindly try to apply rules in situations where they do not make sense. Part of knowing a rule is knowing what situations the rule applies to. You would not name your children using camel case, for example. -ken
Re: pf rule for openvpn
On Sun, Oct 23, 2016 at 4:46 PM, Thuban wrote:
> Here are the relevant parts of my pf.conf :
>
> ext_if = "re0"
> tcp_pass = "{ gopher ipp 8000 }"
> udp_pass = "{ 1194 }"
>
> pass in quick on $ext_if proto tcp to any port $tcp_pass keep state
> pass in quick on $ext_if proto udp to any port $udp_pass keep state
>
> pass out on $ext_if from 10.8.0.0/24 to any nat-to $ext_if
>
> pass out on $ext_if proto { tcp udp icmp } all modulate state
Do you have rules that allow traffic in from tun0? Something like:
pass in quick on tun0 keep state
Otherwise traffic will reach OpenVPN but get no further, being blocked
coming out of the tunnel.
-ken
Re: Cron logs in /var/cron/log instead of /var/log/cron?
On Mon, Oct 3, 2016 at 12:27 AM, wrote: > Is there any harm or issue with setting the log location > of cron logs to /var/log/cron instead, or is it best to leave it > in /var/cron/log? I've moved cron logs to /var/log/cron on some of my own systems, and while cron does work just fine, there are a bunch of changes you need to make: 0. wait until no cron jobs are running or starting soon, that keeps this procedure simple. 1. move the cron log(s): # cd /var/cron # mv log /var/log/cron # mv log.0.gz /var/log/cron.0.gz (continue with log.1.gz, etc. as desired) 2. edit /etc/syslog.conf, changing /var/cron/log to /var/log/cron 3. edit /etc/newsyslog.conf, changing /var/cron/log to /var/log/cron 4. edit /etc/mtree/special, moving the 'log' entry from the /var/cron section to the /var/log section (and renaming from log to cron) Without #4 you will get spurious warnings from security(8) when it can't find cron logs where it expects them. -ken
Re: i386 or amd64?
On Tue, Sep 20, 2016 at 7:38 PM, Jeff Ross wrote: > I've just rented a server with 8GB of ram from m5hosting (based in large > part from the many recommendations I read while searching misc@ on > marc.info). Now the question is: i386 which is what I've always run on my 2 > GB ram server, or amd64? http://www.openbsd.org/amd64.html and > http://www.openbsd.org/i386.html are curiously silent on the amount of ram > that can be accessed. If I have 8GB, I for sure want to use it all. I'm inclined to say, "don't worry about PAE, use amd64 regardless." The reason for this is ASLR (address space layout randomization). ASLR works better when you have a larger address space to work with, and amd64 gives you that larger address space. Plus of course amd64 is the more 'modern' architecture, which implies that it will tend to get more developer attention. With time, i386 will probably be dropped just like 32-bit sparc was. -ken
OpenBSD 6.0 CDs arrived today
Shipments of OpenBSD 6.0 CDs have started arriving, I'm in the USA, New York area. -ken
Re: choosing OpenBSD for fileserver instead of FreeBSD + ZFS
On Wed, Jul 20, 2016 at 7:52 AM, Miles Keaton wrote: > Got a fileserver with a few terabytes of important personal media, like all > old home movies, baby photos, etc. Files that I want my family to have > access to when I die. > > Really it's more of a file archive. A backup. Just rsync + ssh. Serving > it isn't the point. Just preserving it forever. When you die, will there be somebody around who knows how to access these files? I have a file server running OpenBSD and I have both NFS and Samba configured. Samba is the important one if you want people who are less technically savvy to be able to access the data. Samba makes the files easily accessible from a Windows system. Make sure your survivors know how to access this data or your efforts are for nothing. Even with RAID10, your data is still at risk. A fire, for example, can trash everything at once. I back up my server to tape. As businesses upgrade to the latest tape technology the older stuff becomes available relatively cheaply, especially used. I got a used SAS LTO4 tape drive and a SAS controller for it (one OpenBSD supports) on eBay for a good price. LTO4 tapes have a nominal capacity of 800GB uncompressed, or 1600GB compressed; in practice with my particular data I get about 950GB. To protect from loss due to fire, I keep a full set of tapes stored someplace over 100 miles away from my home. Use cron jobs to automate tape backups, then all you have to do is remember to change the tape in the drive. I have a cron job that does a level 1 dump every Sunday so the only thing I normally have to do is change tapes once per week. Periodically I will do a level 0 (full) dump but I do these manually because they will span multiple tapes and a cron job doesn't work well for those. FFS/FFS2 filesystems in OpenBSD work reliably, but fsck can take a while to run on bootup if the server didn't shut down cleanly (e.g. after a power failure). My server is running on fairly old hardware and it takes between 30 and 60 minutes to fsck 6TB of space after an unclean shutdown. Putting your server on a UPS will help you avoid unclean shutdowns due to short power failures, but extended outages will eventually exhaust the batteries. It's possible to have the server automatically shut down when the UPS batteries get low but I don't do this because I'm sure that as soon as I start the shutdown process, the power will come back on. I hold out until the bitter end even if it means a longer fsck later. -ken
Re: pf/routing config for two external interfaces
On Thu, Jul 7, 2016 at 7:19 AM, Jeremy wrote:
> On 28/06/2016 4:38 a.m., Bobby Johnson wrote:
>> I've setup a few OpenBSD machines to do failover with 2 internet
>> interfaces. I didn't use multipath, pf will pass traffic without it. I did
>> find it necessary to specify a reply-to for each of my pass in rules for
>> services on the 2nd interface. For example I would need these 2 rules to
>> pass traffic in on both interfaces, ext_if has the default route and is
>> egress.
>>
>> pass in on egress inet proto tcp from any to $server port 80
>> pass in on $ex2_if inet proto tcp from any to $server port 80 reply-to (
>> $ex2_if $ex2_gw )
>>
> I have revised my pf.conf rules and made changes along the lines suggested
> above.
> ie. ...reply-to ($ext_if2 $ext_gw2)
> (NB: I have also replaced all instances of "egress" with $ext_if1 in
> preparation for switch-over.)
>
> Incoming traffic now works but I'm concerned this is a little clumsy to have
> to duplicate each pass rule and add a reply-to field to each one. Is this
> the best practice ?
PF tags might be useful. I haven't used tags in exactly this way myself
(I use them for other things), but something like this seems reasonable:
match in on egress inet proto tcp from any to $server port 80 tag PASS
...
pass in on $ex1_if tagged PASS
pass in on $ex2_if reply-to $ex2_if tagged PASS
Slightly off topic: in earlier releases I think it used to work putting reply-to
on both. It might have been redundant to put reply-to on the primary interface
but it didn't break anything. now putting reply-to on the primary fouls
things up ("primary" defined as "the interface used by the best-priority
default route").
-ken
Re: Long life on SSD in a firewall environment
On Tue, Jun 21, 2016 at 10:47 AM, Gregory Edigarov wrote: > well, but why not just settup syslogd to fan logs out to some other server? the reason I don't do that is because the sites where I have such firewalls deployed don't have any other servers. I don't want to ship logs over VPN links because those links are not particularly fast. at my 'main' site the firewall is a bigger box with a bigger disk and I don't use MFS for /var/log there. if I were doing so I would certainly consider having syslogd forward logs elsewhere because in general it's a good practice. -ken
Re: Long life on SSD in a firewall environment
On Sun, Jun 19, 2016 at 5:56 AM, Sjöholm Per-Olov wrote: > Does anyone know if there exist any list of recommendations about how to make > an SSD disk to live as long as possible when using it for firewall purpose on > OpenBSD? I don't know of a list, aside from what you find in this thread and similar threads on this list from the past. My own first recommendation is not to worry about it. My second recommendation is: if you must worry about it, change as little as possible. you don't want to make updates difficult due to excessive customization. I am running OpenBSD 5.9 on an Internet-facing router, on Soekris hardware with 4GB mSATA SSD storage. My only concern about SSD durability relates to /var/log and the potential for Internet traffic to cause constant writes there. So I have made minimal changes to guard against that: DO NOT MAKE THESE CHANGES ON YOUR OWN SYSTEM UNLESS YOU UNDERSTAND WHAT THEY DO. 1. when installing OpenBSD, put /var/log on its own 128MB partition. 2. after your first boot, convert /var/log to use MFS: mkdir -p /mfs/log cd /etc mv fstab fstab~ sed -e's|/var/log|/mfs/log|' fstab cat >>fstab swap /var/log mfs rw,nodev,nosuid,-s=128M,-P=/mfs/log 0 0 ^D 3. reboot so that the above /etc/fstab changes take effect. 4. configure rsync to periodically checkpoint /var/log to /mfs/log: pkg_add rsync crontab -e (add the following lines) # # checkpoint log files 10*/4***/usr/local/bin/rsync -ayH --delete-after /var/log/ /mfs/log 5. also save /var/log to /mfs/log on shutdown: cat >>/etc/rc.shutdown /usr/local/bin/rsync -ayH --delete-after /var/log/ /mfs/log ^D I sync /var/log to /mfs/log only every 4 hours because I have reliable power. If you have unreliable power (or unreliable hardware) or your firewall crashes or reboots for unknown reasons you may want to sync more often. Actually in that case you probably shouldn't use an MFS /var/log at all. When I first did this it was more than 2 years ago. Today SSD storage has improved enough that this shouldn't be needed (see my first recommendation above not to worry about it). -ken
Re: Install on compact flash
On Thu, Oct 15, 2015 at 12:19 PM, Paolo Aglialoro wrote: > In order to minimise nand wear off, I would like to put on ramdisk (the > machine would have 2GB ram, so I believe enough also for that, but I still > can upgrade it to 4GB if needed) the parts of the file hierarchy with most > intensive system write I/O, like, for instance, /tmp and I imagine some > parts of /var. > > My questions are two: > 1. What are the dirs I should take into account to go to ramdisk? > 2. What is the correct filesystem type to put in fstab for all the entries > of point 1. in order to store them in ramdisk? I noticed that you have not said that you would like your other filesystems to be read-only, only that you want the 'most intensive' writes to go to a ramdisk. In other words, you don't want your flash storage to be read-only, you merely want it to be read-mostly. I have done something similar myself and what I did was to make 2 mfs filesystems: /tmp and /var/log. here are my /etc/fstab entries: swap /tmp mfs rw,nodev,nosuid,-s=128M 0 0 swap /var/log mfs rw,nodev,nosuid,-s=128M,-P=/mfs/log 0 0 Note that in my setup I have an /mfs/log partition. This was originally the /var/log partition from installation, which I renamed in /etc/fstab later (after doing mkdir -p /mfs/log first). This is a 'durable' copy of /var/log meant to survive crashes, reboots or power failures. The contents of /var/log are periodically checkpointed to /mfs/log using rsync (installed from packages), via a cron job: # checkpoint log files 10 */4 * * * /usr/local/bin/rsync -aH --delete /var/log/ /mfs/log Also, I added this line to /etc/rc.shutdown to handle reboots: /usr/local/bin/rsync -aH --delete /var/log/ /mfs/log If /var/tmp isn't already a symbolic link to /tmp, do that as well to redirect another commonly written directory to ramdisk. You may also want to move cron log files from /var/cron to /var/log (or /var/log/cron if you want them to be separated from other logs). Doing so involves modifying /etc/syslog.conf and /etc/newsyslog.conf. If you do this be prepared for warnings in the nightly security check emails due to the cron log file not being found in its normal location. Leaving an empty log file in the original location is one workaround for this but I haven't tried it. A better workaround may be to modify the nightly check so that it looks for the log file in its new location. -ken
Re: OpenBSD 5.7 CD 2
On Mon, Jun 1, 2015 at 10:13 AM, OpenBSD Store Misc wrote: > CD 2 has been dispatched for replacement on all orders. arrived for me today on the east coast of the USA (New York City area). -ken
Re: Inherited directory file permissions on BSD
On Thu, May 28, 2015 at 8:40 AM, wrote: > i just discovered that on BSD, a file inherits the group permissions from > the directory it is created in (contrary to Linux, which uses the default > group of the user). > > But i failed to find more information on that topic in the man pages > (chmod, chgrp, chown, touch, chflags) or the FAQ, just Otto@ replying on > misc [1]. > > Is this expected to be known, or does this information exist somewhere in > the documentation? more specifically, BSD treats directories as if they always have the setgid bit set. I think this is expected to be known, although it does exist in the documentation (but I had to consult wikipedia to find out where): "man 2 open" says: When a new file is created it is given the group of the directory which contains it. -ken
Re: Random PID implementation and security
On Wed, May 27, 2015 at 5:18 AM, Simon wrote: > So do you confirm that random PID is actually not a security measure? > > It is often presented as is, but it would not be the first time that some > wrong rumors get widespread enough to become accepted as a truth by most > people. language isn't an exact thing. words can mean different things to different people, or different things to the same people in different contexts. I would consider PID randomization to be a security "measure", although I would not consider it a "solution" or "fix" to the problem it addresses. rather, it is a "mitigation" that reduces the severity of a problem without actually fixing it. whether you think of it as a security "measure" depends on whether you define a "measure" as a "fix", or a "mitigation", or as either/both. where we get into trouble is when people mistake it for a "fix" and believe that they no longer need to worry about this problem. that is false. -ken
Re: OpenBSD 5.7 release -- CD2 issues
On Fri, May 15, 2015 at 10:50 AM, Theo de Raadt wrote: > > Sadly, CD2 of the OpenBSD 5.7 shipped in a broken fashion due to > errors at the manufacturing plant. Two mistakes were made. > > In the rush after the first error, this error was not caught in time. > Many people have received (or will soon receive) their package with > this broken disc. Orders which have not yet shipped are being held > back... because... 5.7 (the first batch) was delivered on the east coast of the USA today (New York City area). while CD2 does not boot, one could probably make amd64 install media by booting from CD1, installing the i386 version onto a flash drive, then mounting CD2 and copying the amd64 install files there as well. if you're in a hurry or don't need/want to wait for a replacement CD2, here are the approximate steps to make a flash drive that can be used to install both i386 and amd64. these steps begin after you have installed i386 onto a flash drive but before your first reboot: Copy the i386 install files onto the flash drive: mount /dev/cd0a /mnt2 mkdir -p /mnt/5.7/i386 cd /mnt/5.7/i386 (cd /mnt2/5.7/i386; tar cf - .) | tar xvfp - cd /; umount /mnt2 Load the amd64 CD and copy the amd64 install files onto the flash drive: mount /dev/cd0a /mnt2 mkdir -p /mnt/5.7/amd64 cd /mnt/5.7/amd64 (cd /mnt2/5.7/amd64; tar cf - .) | tar xvfp - cd /; umount /mnt2 Now rename the files in /mnt/5.7/amd64 to have the proper case. Use the filenames in /mnt/5.7/i386 as a model for how the names should look. I'm supposing the fact that the filenames all appear to be uppercase is an indication of why CD2 is considered 'broken'. To install amd64 from this flash drive, boot from it and at the boot> prompt type (quickly, before it automatically boots i386): boot /5.7/amd64/bsd.rd If you want to install i386, type this instead: boot /5.7/i386/bsd.rd If you don't type anything at the boot> prompt, i386 will boot the GENERIC kernel, which might be useful if you want to capture a dmesg on a new system or something. I tested this procedure just now, but only to the point of booting /5.7/amd64/bsd.rd. I did not actually try to install amd64 this way (at least, not yet) but I don't see any particular reason it shouldn't work. assuming you can boot your system from a USB flash drive, of course. if you can't this won't help you. I've used a similar procedure in the past to make a 5.4 flash drive that I could use to install OpenBSD onto a Soekris box, when I was sure I was going to install from a flash drive, but not yet sure whether I would use i386 or amd64 (so I made sure I had both). -ken
Re: Screwed up copying partition to another disk
On Fri, Apr 10, 2015 at 1:00 PM, Chris Bennett < chrisbenn...@bennettconstruction.us> wrote: > Works fine, except I overlooked mounting /DST on first try, so > everything ended up in / until full. I also started deleting those files > until I realized I was in /SRC and Ctrl C it. > Now I have a problem, I have > /dev/sd0a 1005M 1005M -50.1M 105% / > > I cannot find those files (would really like to have them). > if you cannot find the files that are making /dev/sd0a so full, I am guessing you remembered later to mount /DST. try unmounting /DST, then cd /DST and you should see your files. when you mount a filesystem on a directory, the previous contents of the directory become inaccessible. in order to access those files/subdirectories you need to unmount the filesystem that is covering them up. -ken
Re: I found a sort bug! - How to sort big files?
I don't know why sort is giving you such problems. there may be something unusual about your specific input that it wasn't designed to handle (or it might simply be a latent bug that has never been identified and fixed). when I need to sort large files, I split(1) them into smaller pieces, then sort(1) the pieces individually, then use sort(1) (with the -m option) to merge the sorted pieces into a single large result file. this has always worked reliably for me (and because I was raised using 8-bit and 16-bit computers I don't have any special expectations that programs should "just work" when given very large inputs). even if you think doing all this is too much bother, try doing it just once. you might be able to identify a specific chunk of your input that's causing the problem, which will help move us all towards a proper solution (or at least a caveat in the man page). -ken On Sun, Mar 15, 2015 at 9:53 AM, sort problem wrote: > Whoops. At least I thought it helped. The default sort with the "-H" > worked for 132 minutes then said: no space left in /home (that had before > the sort command: 111 GBytes FREE). And btw, df command said for free > space: "-18 GByte", 104%.. what? Some kind of reserved space for root? > > > Why does it takes more then 111 GBytes to "sort -u" ~600 MByte sized > files? This in nonsense. > > > So the default "sort" command is a big pile of shit when it comes to > files bigger then 60 MByte? .. lol > > I can send the ~600 MByte txt files compressed if needed... > > I was suprised... sort is a very old command.. > > > Original Message > From: "sort problem" > To: andreas.zeilme...@mailbox.org > Cc: misc@openbsd.org > Subject: Re: I found a sort bug! - How to sort big files? > Date: Sat, 14 Mar 2015 08:39:55 -0400 > > o.m.g. It works. > > Why doesn't sort uses this by default on files larger then 60 MByte? > > Thanks! > > Original Message > From: Andreas Zeilmeier > Apparently from: owner-misc+m147...@openbsd.org > To: misc@openbsd.org > Subject: Re: I found a sort bug! - How to sort big files? > Date: Sat, 14 Mar 2015 13:16:05 +0100 > > > On 03/14/15 12:49, sort problem wrote: > > > Hello, > > > > > > -- > > > # uname -a > > > OpenBSD notebook.lan 5.6 GENERIC.MP#333 amd64 > > > # > > > # du -sh small/ > > > 663Msmall/ > > > # ls -lah small/*.txt | wc -l > > > 43 > > > # > > > # cd small > > > # ulimit -n > > > 1000 > > > # sysctl | grep -i maxfiles > > > kern.maxfiles=10 > > > # > > > # grep open /etc/login.conf > > > :openfiles-cur=10:\ > > > :openfiles-cur=128:\ > > > :openfiles-cur=512:\ > > > # > > > # sort -u *.txt -o out > > > Segmentation fault (core dumped) > > > # > > > -- > > > > > > This is after a minute run.. The txt files have UTF-8 chars too. A > line is maximum a few ten chars long in the txt files. All the txt files > have UNIX eol's. There is enough storage, enough RAM, enough CPU. I'm even > trying this with root user. The txt files are about ~60 000 000 lines.. not > a big number... a reboot didn't help. > > > > > > > > > > > > Any ideas how can I use the "sort" command to actually sort? Please > help! > > > > > > > > > > > > Thanks, > > > > > > btw, this happens on other UNIX OS too, lol... why do we have the sort > command if it doesn't work? > > > > > > > Hi, > > > > have you tried the option '-H'? > > The manpage suggested this for files > 60MB. > > > > > > Regards, > > > > Andi
Re: lynx is gone?
On Wed, Mar 4, 2015 at 1:48 PM, Jeff St. George wrote: > Its not in my pay grade to offer a technical opinion on Lynx removal! > But ,,WHAT r u folks using instead, considering?? > typically when I am setting up a server I have a laptop with me. the laptop will either have my pre-planning notes, or if it doesn't have that, it will be where I record my as-built notes. either way, at the end I will have a record on my laptop of all the key information I would need if I ever have to rebuild that particular server. since I have my laptop with me anyway, if I need to look at any web pages during the server install, I use that. if I really need to fetch a web page on the server itself, I use ftp (which also supports http). if it's not a server (i.e. I'm setting up a workstation) then I'll typically want X and something like Firefox. -ken
Re: File transfer from NetBSD to OpenBSD
FAT (and FAT32) would probably involve less experimentation. to bypass the limitations of FAT, I recommend using tar(1) and split(1). tar cfC - /filesystem-to-back-up . | split -b 2000m that will produce a tar file split into 2GB chunks named xaa, xab, xac, etc. to restore: cat x?? | tar xfC - /directory-to-restore-into . this assumes that NetBSD tar and split are substantially similar to OpenBSD's. -ken On Sun, Mar 1, 2015 at 11:55 AM, Josh Grosse wrote: > On 2015-03-01 11:40, etie...@magickarpet.org wrote: > > Could anyone recommend which filesystem type to use when backing up a >> few hundred GB of files from NetBSD onto a USB disk, planning to >> restore them on an OpenBSD machine. I remember distantly that last >> time I tried with FFS, it didn't work. >> > > You might experiment with ext2fs. IIRC, FAT has two strikes against it: > owner/mode, and 4GB individual filesize limit. NTFS (built-in, or FUSE) > has its own owner/mode translation issues, such that you would liely want > to archive files as intermediate step. > > Of course, network file transfers, if you had the bandwidth, would preclude > the need for any foreign file systems.
Re: Alternative way to get sources, CVS slow
the OpenBSD CD-ROM set includes the -RELEASE sources. using those as a starting point, updating to -STABLE should be very fast. -ken On Sat, Feb 21, 2015 at 1:06 PM, Henrique Lengler wrote: > Hi, > > I'm trying to keep and maintain a copy of -stable source code in my system. > The problem is that I can't work with CVS. > It is too slow to download. My internet can download things at 500kb/s - > 1MB/s, > but when I am doing a checkout, the download stay too slow, I already > tried with a > bunch of mirrors, and it is almost the same thing. I don't know if the > problem is that > all CVS mirrors are slow. > I let my computer all the last day doing a checkout for src ports and > xenocara. After > 10 hours it was in ports yet. > > Also, the worst problem is that my internet connections sometimes drop, > and so in an > attempt to continue the interrupted checkout I run the command again, the > problem is > that it takes about a half hour to start to continue getting the code, > this when it > works, because sometimes after all this time I get: > Write failed: Broken pipe > Also sometimes looks like it is getting everything again, because it says > cvs server: Updating foo > to every file already in the folder. > > I'm looking to a way to get this sources, there is a long time I'm trying > and it > ever happens some problem like this, and I can't continue to get the > sources, so I > need to delete everything a start again. > > CVS looks too complicated and confuse. > I would like to be able to get from http, git, ftp or anything sipler and > faster. > Is there any alternative? > -- > Regards > > Henrique Lengler
Re: OpenBSD Tablet-ish
On Thu, Feb 19, 2015 at 3:43 PM, Robert wrote:
>
> Anything that can be acquired outside of a museum? ;)
>
> Has someone tested OpenBSD on one of the current (Atom/Windows-based)
> 8-10" tablets?
> E.g., Lenovo Yoga 2 or Ideapad
> They seem to have a BIOS that can be configured; maybe Secure Boot can be
> disabled...
>
I didn't reply earlier because I thought the Dell XPS 12 wouldn't meet your
requirements, but I have booted OpenBSD 5.4 on it, although I did have to
disable Secure Boot in the BIOS first. dmesg follows:
OpenBSD 5.4 (GENERIC.MP) #44: Tue Jul 30 12:13:32 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
RTC BIOS diagnostic error 80
cpu0: Intel(R) Core(TM) i5-3437U CPU @ 1.90GHz ("GenuineIntel" 686-class)
1.80 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,D
S-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
real mem = 2839851008 (2708MB)
avail mem = 2781995008 (2653MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/01/13, BIOS32 rev. 0 @ 0xef725,
SMBIOS rev. 2.7 @ 0xe6530 (69 entries)
bios0: vendor Dell Inc. version "A08" date 08/01/2013
bios0: Dell Inc. XPS 12 9Q23
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA SLIC UEFI SSDT SSDT SSDT SSDT ASF! HPET APIC
MCFG WDAT SSDT BOOT SSDT ASPT FPDT MSDM SSDT SSDT DMAR
acpi0: wakeup devices P0P1(S4) GLAN(S4) EHC1(S0) EHC2(S4) XHC_(S0) HDEF(S0)
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
PXSX(S4) RP05(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: apic clock running at 99MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3437U CPU @ 1.90GHz ("GenuineIntel" 686-class)
2.40 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,D
S-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-3437U CPU @ 1.90GHz ("GenuineIntel" 686-class)
2.40 GHz
cpu2:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,D
S-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-3437U CPU @ 1.90GHz ("GenuineIntel" 686-class)
2.40 GHz
cpu3:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,D
S-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus 2 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0
acpicpu0 at acpi0: C2, C1, PSS
acpicpu1 at acpi0: C2, C1, PSS
acpicpu2 at acpi0: C2, C1, PSS
acpicpu3 at acpi0: C2, C1, PSS
acpibtn0 at acpi0: PWRB
acpibat0 at acpi0: BAT1 model "PABAS0241231" serial 41167 type Li-Ion oem
"Simplo"
acpiac0 at acpi0: AC unit online
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
bios0: ROM list: 0xc/0xee00
ipmi: unknown register spacing
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 2395 MHz: speeds: 1901, 1900, 1800, 1700, 1600,
1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
0:4:0: mem address conflict 0xfed98000/0x8000
pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09
intagp0 at vga1
agp0 at intagp0: aperture at 0xb000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1920x1080
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
vendor "Intel", unknown product 0x0153 (class DASP subclass miscellaneous,
rev 0x09) at pci0 dev 4 function 0 not configured
"Intel 7 Series xHCI" rev 0x04 at
Re: Best filesystem & options for large drive
here's an example for fsck on a largish volume with a lot of files:
# df -hi /nfs/archive
Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted
on
/dev/sd0e 3.6T2.3T1.2T67% 3900811 119021683 3%
/nfs/archive
# umount /nfs/archive
# \time -l fsck -f /dev/sd0e
** /dev/rsd0e
** File system is already clean
** Last Mounted on /nfs/archive
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
3900811 files, 307622602 used, 179239875 free (49355 frags, 22398815
blocks, 0.0% fragmentation)
1966.70 real14.68 user36.78 sys
137096 maximum resident set size
0 average shared memory size
0 average unshared data size
0 average unshared stack size
3561095 minor page faults
4 major page faults
0 swaps
0 block input operations
5 block output operations
0 messages sent
0 messages received
0 signals received
526407 voluntary context switches
30 involuntary context switches
#
note that with nearly 4 million files, the amount of time required by fsck
increased dramatically(over 30 minutes) but memory usage increased much
less (only 137MB). this particular system has 12GB RAM but doesn't appear
to ever use much of it. the sd0 device is a 6TB RAID10 array (4x 3TB
drives) on an Areca ARC1110 PCI-X controller (in a 64-bit 133MHz PCI-X
slot), partitioned with 1/3 of the space on sd0d and the remaining 2/3 on
sd0e. /dev/sd0d was mostly idle (although still mounted) while fsck was
running.
-ken
On Tue, Feb 10, 2015 at 5:35 PM, Jan Stary wrote:
> On Feb 10 17:48:22, na...@mips.inka.de wrote:
> > On 2015-02-10, yary wrote:
> >
> > > I know FFS2 can handle that size easily, but I'm worried about fsck
> > > taking forever. This machine will have 1.5GB RAM, from what I've read
> > > that's not enough memory to fsck a 4TB volume without painful
> > > swapping.
> >
> > It vastly depends on the number of files you have on there.
>
> And if you know in advance that the files will be large
> ("video editing"?) and there will not be many of them,
> you might benefit from 'newfs -i' (and other options)
> when creating the file system.
Re: Too much SUID/SGID files!
(tech removed from reply, don't cross-post) If you consistently log on to your system as root, then you probably don't need many SUID or SGID executables at all, since everything (interactive) will run with root privileges anyway. But if you usually log on as an unprivileged user (as you should if you really care about security) then you will find that certain things don't work without SUID or SGID. Which is exactly why SUID or SGID are used. To use your wall / write example, try removing the SGID bit from those executables, then (as a regular user) try using them to see if they work. You should discover that an unprivileged user does not have the ability to write to other users' terminals, which prevents write from working. In order to be able to write to a terminal other than your own, you need additional privileges. root privileges would work, but that is much more than you need, which is why the 'tty' group exists. That group has just the rights that wall / write need, and not a lot else. If you are sure you will never need wall / write, you can remove the setgid bit from them, or even delete them entirely. If you aren't sure (e.g. are you certain that shutdown doesn't use wall to send shutdown notification messages to users?) then you should leave them alone. as a general rule, it is safe to assume that if OpenBSD installs programs with setuid or setgid bits set, then those programs need them to be that way. you are welcome to investigate each case individually, and if you discover that a specific program doesn't need to be setuid/setgid, or can be rewritten to work without them, then you are welcome to submit a patch making it so. -ken On Tue, Jan 6, 2015 at 2:27 AM, whoami toask wrote: > Hello, > > isn't there too much SUID/SGID files on a default OpenBSD install? > > Can this number be reduced? > > Example: why does wall, write, modstat need an SGID? > > # uname -a > OpenBSD notebook.lan 5.6 GENERIC.MP#333 amd64 > # find / -perm -4000 -o -perm -2000 -ls -print > 78047 5856 -rwxr-sr-x1 root auth 2970920 Aug 6 21:45 > /usr/X11R6/bin/xlock/usr/X11R6/bin/xlock > 78068 1216 -rwxr-sr-x1 root utmp 592056 Aug 6 22:09 > /usr/X11R6/bin/xterm/usr/X11R6/bin/xterm > 1147497 60 -r-xr-sr-x1 root kmem30200 Jul 31 11:50 > /usr/local/bin/libgtop_server2/usr/local/bin/libgtop_server2 > 78031 32 -r-xr-sr-x1 root utmp15864 Jul 31 09:57 > /usr/local/libexec/gnome-pty-helper/usr/local/libexec/gnome-pty-helper > 155910 84 -r-xr-sr-x4 root crontab 41752 Aug 8 08:06 > /usr/bin/at/usr/bin/at > 155910 84 -r-xr-sr-x4 root crontab 41752 Aug 8 08:06 > /usr/bin/atq/usr/bin/atq > 155910 84 -r-xr-sr-x4 root crontab 41752 Aug 8 08:06 > /usr/bin/atrm/usr/bin/atrm > 155910 84 -r-xr-sr-x4 root crontab 41752 Aug 8 08:06 > /usr/bin/batch/usr/bin/batch > 155943 72 -r-xr-sr-x1 root crontab 36504 Aug 8 08:06 > /usr/bin/crontab/usr/bin/crontab > 156014 24 -r-xr-sr-x1 root auth11672 Aug 8 08:06 > /usr/bin/lock/usr/bin/lock > 156019 60 -r-xr-sr-x1 root daemon 28952 Aug 8 08:06 > /usr/bin/lpq/usr/bin/lpq > 156033 20 -r-xr-sr-x1 root _lkm 8952 Aug 8 08:06 > /usr/bin/modstat/usr/bin/modstat > 156035 292 -r-xr-sr-x1 root kmem 148216 Aug 8 08:06 > /usr/bin/netstat/usr/bin/netstat > 156093 24 -r-xr-sr-x1 root auth11544 Aug 8 08:06 > /usr/bin/skeyaudit/usr/bin/skeyaudit > 156094 16 -r-xr-sr-x1 root auth 8184 Aug 8 08:06 > /usr/bin/skeyinfo/usr/bin/skeyinfo > 156095 44 -r-xr-sr-x1 root auth20632 Aug 8 08:06 > /usr/bin/skeyinit/usr/bin/skeyinit > 156105 704 -r-xr-sr-x1 root _sshagnt 333656 Aug 8 08:07 > /usr/bin/ssh-agent/usr/bin/ssh-agent > 156112 284 -r-xr-sr-x1 root kmem 144568 Aug 8 08:06 > /usr/bin/systat/usr/bin/systat > 156146 32 -r-xr-sr-x1 root tty 15928 Aug 8 08:06 > /usr/bin/wall/usr/bin/wall > 156152 28 -r-xr-sr-x1 root tty 13080 Aug 8 08:06 > /usr/bin/write/usr/bin/write > 103939 40 -r-xr-sr-x4 root _token 20344 Aug 8 08:06 > /usr/libexec/auth/login_activ/usr/libexec/auth/login_activ > 103939 40 -r-xr-sr-x4 root _token 20344 Aug 8 08:06 > /usr/libexec/auth/login_crypto/usr/libexec/auth/login_crypto > 103943 40 -r-xr-sr-x1 root _radius 19928 Aug 8 08:06 > /usr/libexec/auth/login_radius/usr/libexec/auth/login_radius > 103945 24 -r-xr-sr-x1 root auth11608 Aug 8 08:06 > /usr/libexec/auth/login_skey/usr/libexec/auth/login_skey > 103939 40 -r-xr-sr-x4 root _token 20344 Aug 8 08:06 > /usr/libexec/auth/login_snk/usr/libexec/auth/login_snk > 103939 40 -r-xr-sr-x4 root _token 20344 Aug 8 08:06 > /usr/libexec/auth/login_token/usr/libexec/auth/login_token > 103947 40 -r-xr-sr-x1 root auth20408
Re: Changing naming order of HDD SD drives on boot by kernel
it occurs to me, after a night's rest, that if you want short easy-to-remember device names that don't change when drives are reordered etc., then it might work to create 'alias' device nodes. put something into rc.local to look up certain duids (e.g. disklabel | head -1 ), look up the major/minor numbers of the 'native' device nodes for that disk, then make (or replace) your 'alias' device nodes with the same numbers. sd0a might not always be the sd0a you wanted, but there's no reason that "hd0a" can't be -- it just needs to point to whatever partition your desired sd0a is living on today. this could probably be done with a shell script and some sed processing, although maybe awk or perl might work better. note that this won't work for things like /etc/fstab unless you do all this work in /etc/rc before the filesystems get mounted (and in that case you need to limit yourself to the tools in /bin and /sbin). exercise left for the reader -- I've had a night's rest but not my morning caffeine. -ken On Sun, Aug 17, 2014 at 3:17 AM, Denis Lapshin wrote: > I've simply disabled detecting any USB mass storage devices by kernel. > Since then there is no problem with reordering SDx devices and all works > good except usb related storage devices... > > Cheers > > > On 15.08.2014 15:44, Denis Lapshin wrote: > >> May I use DUID in my case when I have a USB card reader which has no >> flash card in it? >> >> How to fix using DUID for SD1 (fstab with SD1 DUIDs is below) as boot >> disk don't mind on any other USB disks, readers (without card, for >> instance) connected to the system during boot? >> >> How to make USB SDx staff working with softraid encrypted HDD which must >> be mounted as SD1 by the kernel (using DUID), but physically determined as >> SD0. >> >> Cheers >> >> On 15.08.2014 13:51, Joel Sing wrote: >> >>> On Fri, 15 Aug 2014, Denis Lapshin wrote: >>> My fstab has identity for main boot HDD: 548ac03903a985e9.a / ffs rw 1 1 548ac03903a985e9.g /home ffs rw,nodev,nosuid 1 2 548ac03903a985e9.d /tmp ffs rw,nodev,nosuid 1 2 548ac03903a985e9.f /usr ffs rw,nodev 1 2 548ac03903a985e9.e /var ffs rw,nodev,nosuid 1 2 835806792ad105b8.b none swap sw 127.0.0.1:/home/cvs /var/www/cvs nfs rw,nodev,nosuid 0 0 but once I installed usb flash drive and reboot the system, my main boot HDD stay SD3 instead of SD1 as it should be. The HDD is encrypted by softraid discipline additionally, so kernel physically determine it as SD0, softraid mount it as SD1. Any additional drive detected by kernel stop booting from main HDD SD0=SR SD1 because of renaming all SD drives. >>> Why? >>> >>> What is referencing the sd0/sd1 device directly, rather than using a >>> DUID? >>> >>> In FAQ I found about drives renumeration by kernel: "The first drive of a particular type identified by OpenBSD will be drive '0', the second will be '1', etc. So, the first IDE-like disk will be wd0, the third SCSI-like disk will be sd2. If you have two SCSI-like drives and three IDE-like drives on a system, you would have sd0, sd1, wd0, wd1, and wd2 on that machine. The order is based on the order they are found during hardware discovery at boot. There are a few key points to keep in mind: * Drives may not be numbered in the same order as your boot ROM attempts to boot them (i.e., your system may attempt to boot what OpenBSD identifies as wd2 or sd1). Sometimes you may be able to change this, sometimes not. * Removing or adding a disk may impact the identity of other drives on the system. " I would like bind SD labels to drives in invariable fashion. >>> In short, there is no way to do this - this is what DUIDs are for. >>> >>> On 15.08.2014 11:51, Daniel Jakots wrote: > On Fri, 15 Aug 2014 11:37:56 +0400, Denis Lapshin > > wrote: > >> Is it possible to change or set fixed device names for drives like >> SD0, SD1, SD2, SD3 and so on. >> > http://www.openbsd.org/faq/faq14.html#DUID > > > Cheers,
Re: NFS server export node
On Mon, Apr 21, 2014 at 3:39 PM, Alessandro DE LAURENZIS < just22@gmail.com> wrote: > Folks, > > still unclear after reading the hier man page where is the most suitable > node for a NFS server export directory. > as far as I know there's no standard for this. I have been using /nfs, in a vaguely similar way to how /afs is used for AFS, but only because I dedicate a filesystem to NFS when I use it (and mount that filesystem as /nfs). when it is practical to do so, I use /nfs for both the server side and the client side -- on the server I have an /nfs filesystem which may contain an exported directory /nfs/foo, and on the client side I either have another /nfs filesystem (if it's a peer server with exports of its own) or an /nfs folder in the root filesystem (for a client-only machine); in either case /nfs then contains an /nfs/foo mount point. in this way the absolute pathname to the 'foo' volume is always the same regardless of whether you're on the client or server. -ken
Re: Request for Funding our Electricity
I do not doubt that emulators can be useful for some things. Indeed, I use them myself when real hardware isn't available. but emulators have limits -- invariably they are written to emulate certain things accurately (albeit imperfectly, because all programmers make mistakes) while other things deemed less important are emulated less accurately, or simply substituted with ideal mathematical constructs. lately, I've been running a PDP-11 emulator that doesn't even bother to simulate memory errors -- every byte of memory in the simulated system is error-free, and therefore parity error traps are never generated (and the parity trap handler in the operating system is therefore never exercised). you are not going to track down a cache coherency bug using an emulator that doesn't attempt to emulate cache *incoherency*. really, in order to know whether emulation is going to be useful, you need to consult an expert in the particular part of the system you're trying to emulate. this means, if you're looking for bugs in an operating system, you need to talk to people who write operating systems, because they are the experts on the hardware behaviors that actually matter. some things that an emulator faithfully reproduces probably aren't that important to an operating system, while other things the emulator doesn't bother to accurately simulate may be critically important. how can we tell the difference? if only we had someone with years of experience doing this type of work who could tell us whether emulation is adequate in this situation or not. -ken
Re: fw_update
On Wed, May 9, 2012 at 3:33 PM, mark sullivan wrote: > I would like to hear your arguments on this and if there is a simple way > to disable fw_update and uninstall in general everything propietary > affecting the network card that I have not been warned about. I read on the > FAQ that I should have been asked about this firmware but I wasnB4t! (amd64 > cd installer). > are you confusing "proprietary" with "third-party"? the firmware you're concerned about is provided by the card's manufacturer (or the chipset manufacturer) and the card (or chip) won't work without it. the reason OpenBSD needs to download it is because the manufacturer won't allow OpenBSD to include it on the CD. if you don't download it, the device won't work -- if the device could work effectively without it, OpenBSD would not go to the trouble of downloading it to begin with. this is not the same thing as third-party firmware which replaces the manufacturer's firmware. examples of this kind of thing are OpenWRT and Tomato firmware which replace the factory firmware on certain consumer-grade routers. -ken
Re: Multiple ISP-connections/Routing/Packet filtering
On Tue, Jan 10, 2012 at 1:41 PM, Dr.-Ing. Torsten Finke < torsten.fi...@igh-essen.com> wrote: > On my firewall I have TWO different internet connections. It is simple to > forward - for instance ssh - > from both connections to an internal machine. Now this machine answers and > the > firewall sends the reply back. How can I force the firewall to send the > reply > over exactly that interface the request came in? The problem is that the > client anywhere on the internet expects the answer from the very address it > had contacted. If now the reply comes from another address, it will get > lost. > I am doing this using OpenBSD 4.6, without any apparent problems, using the following syntax: pass in log quick on $pri inet proto tcp to ($pri) port 1194 pass in log quick on $sec reply-to $sec inet proto tcp to ($sec) port 1194 Unfortunately, the pf.conf syntax has changed since v4.6 and while I do plan to upgrade my own firewall to v5.0 (I've bought the CD already) I haven't yet had time to perform the upgrade. As a result, I haven't worked out what the equivalent 'modern' syntax would be, but you might be able to get some hints from what I'm using in v4.6. -ken
