Re: 6.9 on VMware Workstation networking issues
Hi Masato,
Thanks for checking. I'm currently stuck with Workstation Pro 15.5.7
build-17171714.
It seems likely that it is an interaction between Workstation and some
changes between 6.8 and 6.9 that causes this regression. It's not clear
whose fault it is for this misbehavior. However, none of the previous
OpenBSD versions, various Linux distros, and Windows VMs I'm running
exhibit this.
It would be interesting to know, if there is more than just ENOBUFS and
high Ofail numbers that I could look for to pinpoint the root cause ...
Best regards,
-Moritz
On 12.05.21 11:14, Masato Asou wrote:
I've also tried VMware Workstation 16 Player on Windows10 Pro and the
netowrk is working fine.
--
ASOU Masato
From: Masato Asou
Date: Wed, 12 May 2021 12:51:48 +0900 (JST)
Hi Moritz,
I upgraded with the following command on my OpenBSD 6.8 release, and
the network is working fine.
$ doas sysupgrade
I am using ESXi 6.7 and VMware Fusion 12.1.1 and em0 both environment,
and network is working fine both environment.
Isn't it a VMware Workstation problem?
Can you try VirtualBox?
--
ASOU Masato
From: Moritz Grimm
Date: Wed, 12 May 2021 00:32:42 +0200
Hi,
Networking has become unusable in all of my virtual installs of 6.9 on
VMware Workstation after an (otherwise uneventful) sysupgrade from 6.8
to 6.9. They've been working for years and I've upgraded them several
times without any issues so far.
netstat -ni shows a huge number of Ofail and ping almost always prints
and error from sendmsg ("No buffer space available"), but the
occasional ping and DNS lookup does go through (at a success rate of
<5%). These are the only error messages I am getting.
I'm using vmx(4), but also tried em(4) without any success.
None of the upgrade69.html configuration changes are applicable, and
my pf.conf parses without errors in 6.9.
The dmesg output (from version 6.8 below) is almost identical in 6.9,
which just shows slightly less memory available.
I've run out of debugging ideas and would appreciate some help. My
only "solution" right now was to revert to a 6.8 snapshot. I'm also a
bit worried that I might run into similar issues on my bare metal
installs (which are all "production"), so I haven't tried those, yet.
Thanks,
-Moritz
OpenBSD 6.8 (GENERIC.MP) #5: Mon Feb 22 04:36:10 MST 2021
r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 519962624 (495MB)
avail mem = 489213952 (466MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0010 (620 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 02/27/2020
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3)
S8F0(S3) S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3)
S25F(S3) PE40(S3) S1F0(S3) PE50(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz, 2593.36 MHz, 06-9e-0d
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,XSAVEC,XSAVES
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 65MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz, 2593.40 MHz, 06-9e-0d
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,XSAVEC,XSAVES
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 0, package 2
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
"PNP0A05" at acpi0 not configured
acpibat0 at acpi0: BAT1 model "VMware Virtual Batt"
acpiac0 at acpi0: AC unit online
"PNP0A05" at acpi0 not configured
"PNP0A05" at acpi0 not configured
"PNP0A05" at acpi0 not configured
"PNP0
6.9 on VMware Workstation networking issues
Hi,
Networking has become unusable in all of my virtual installs of 6.9 on
VMware Workstation after an (otherwise uneventful) sysupgrade from 6.8
to 6.9. They've been working for years and I've upgraded them several
times without any issues so far.
netstat -ni shows a huge number of Ofail and ping almost always prints
and error from sendmsg ("No buffer space available"), but the occasional
ping and DNS lookup does go through (at a success rate of <5%). These
are the only error messages I am getting.
I'm using vmx(4), but also tried em(4) without any success.
None of the upgrade69.html configuration changes are applicable, and my
pf.conf parses without errors in 6.9.
The dmesg output (from version 6.8 below) is almost identical in 6.9,
which just shows slightly less memory available.
I've run out of debugging ideas and would appreciate some help. My only
"solution" right now was to revert to a 6.8 snapshot. I'm also a bit
worried that I might run into similar issues on my bare metal installs
(which are all "production"), so I haven't tried those, yet.
Thanks,
-Moritz
OpenBSD 6.8 (GENERIC.MP) #5: Mon Feb 22 04:36:10 MST 2021
r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 519962624 (495MB)
avail mem = 489213952 (466MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0010 (620 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 02/27/2020
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3)
S8F0(S3) S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3)
PE40(S3) S1F0(S3) PE50(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz, 2593.36 MHz, 06-9e-0d
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,XSAVEC,XSAVES
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 65MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz, 2593.40 MHz, 06-9e-0d
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,XSAVEC,XSAVES
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 0, package 2
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
"PNP0A05" at acpi0 not configured
acpibat0 at acpi0: BAT1 model "VMware Virtual Batt"
acpiac0 at acpi0: AC unit online
"PNP0A05" at acpi0 not configured
"PNP0A05" at acpi0 not configured
"PNP0A05" at acpi0 not configured
"PNP0A05" at acpi0 not configured
"PNP0A05" at acpi0 not configured
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
pvbus0 at mainbus0: VMware
vmt0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus
disabled
"VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured
vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
mpi0 at pci0 dev 16 function 0 "Symbios Logic 53c1030" rev 0x01: apic 1
int 17
mpi0: 0, firmware 1.3.41.32
scsibus1 at mpi0: 16 targets, initiator 7
ppb1 at pci0 dev 17 function 0 "VMware PCI" rev 0x02
pci2 at ppb1 bus 2
uhci0 at pci2 dev 0 function 0 "VMware UHCI" rev 0x00: apic 1 int 18
ehci0 at pci2 dev 2 function 0 "VMware EHCI" rev 0x00: apic 1 int 16
usb0
Re: Updating past 5.4-current flag day w/ SSH only (amd64, maybe others)
Hi Paul, Good feedback, thanks. > | # cp -p bsd.mp /bsd && cp -p bsd.rd /bsd.rd && sync > > So don't copy bsd.rd when copying bsd.mp exited non 0 ? I very much expect that to work, so I'd rather have it stop in case of error. Personal preference, I guess. > | d) Destroy the system for good: > | # for x in base54.tar comp54.tar man54.tar game54.tar xbase54.tar > | xshare54.tar xfont54.tar xserv54.tar; do echo $x; /bin54/tar xphf $x -C > | /; /bin54/sync; done > > Reverse the list of files and you won't need your /bin54/tar (and you > can continue using gzip'ed tarballs). In fact, all you really need is > to stick base54 at the end of the list. Yes, even though that deviates from the order the installer uses. The results are probably the same, but I would want to double-check that first. Also, the order is so engrained from years of typing them, I often try to include the misc set after comp ... > | 12. Re-add packages as per current.html: > | > | # pkg_add -z -l /root/pkg_list_manual > | # pkg_add -za -l /root/pkg_list_full > > I don't really understand why you're doing the -za dance with the full > pkg list. For all those dependencies that were required for the > manually installed packages ? Or for all the dependencies of manually > added packages that you've since deleted ? I simply merged in the steps from current.html, to make the instructions comparable. (Convention wins.) I like how this make sure that the resulting system is as close as possible to before the update. Moritz
Updating past 5.4-current flag day w/ SSH only (amd64, maybe others)
Hi, This is an FYI on how to move past flag day with SSH access only. I used this process on my local workstation first, then verified it on a VM actually using SSH only (both amd64). I'll do it again when updating a bunch of important boxes to 5.5 in 2014, so this is also for the archives in case I lose my notes ... For every step that counts: Work in a real root shell. Do not rely on sudo for this, except for maybe an initial ``sudo su -l''. 1. Download the new installation sets (you need bsd* and *.tgz). If you care about the original sets, make another copy of them before the next step. 2. Unzip the tarballs, to remove any dependency on gzip(1): # for x in *.tgz; do gunzip $x; done 3. Copy essential pre flag day files. NB: My use of sync(1) is, first and foremost, to make me feel good. It's maybe reducing certain risk, but it won't eliminate it. # mkdir /bin54 # cp -p /sbin/reboot /bin/tar /bin/sync /bin54 4. Save packages information as per current.html: # pkg_info -mq > /root/pkg_list_manual # pkg_info -q > /root/pkg_list_full 5. Before continuing on this soon-to-be destructive path, put the tip of your right hand's little finger on your slightly puckered lips, raise your left eyebrow, and think: "Do I really want to continue?" 6. Update /etc. 7. Allow login after first reboot post flag-day: # cat << EOF >> /etc/rc.local echo " FLAG DAY " pwd_mkdb /etc/master.passwd cp /dev/null /var/log/lastlog cp /dev/null /var/run/utmp echo " FLAG DAY " EOF 8. Uninstall all but (any) firmware packages as per current.html, but maybe do some extra things, too: a) Stop all non-base daemons, make database dumps, the one or other last-minute backup ... b) Re-visit current.html for extra migration steps w/ 3rd party software, like the rrdtool stuff. c) # pkg_delete -X /var/db/pkg/*-firmware-[0-9]* 9. Install new kernel, unpack install sets (previously unzipped): a) Make backups of your kernels to have *something* to boot to if all goes wrong: # for x in /bsd*; do cp -p $x $x.54; sync; done b) Install the new kernel. This is a lazy gamble, and not a replacement for doing it properly as per Nick's FAQ: # cp -p bsd.mp /bsd && cp -p bsd.rd /bsd.rd && sync c) optional: use this opportunity for some (incomplete) housekeeping: # rm -rf /usr/include /usr/libdata/perl5/site_perl/amd64-openbsd /usr/share/locale /usr/share/man d) Destroy the system for good: # for x in base54.tar comp54.tar man54.tar game54.tar xbase54.tar xshare54.tar xfont54.tar xserv54.tar; do echo $x; /bin54/tar xphf $x -C /; /bin54/sync; done 10. Reboot immediately afterwards; the system is no longer good for anything else: # /bin54/reboot Good luck. 11. Clean up upon successful re-login: a) # rm -r /bin54 /bsd*.54 b) Remove FLAG DAY stuff from rc.local. c) Look for coredumps that accumulated since the unpacking of baseXX.tgz, as there might be some due to (then) bad system calls. # find / -type f -name '*.core' 12. Re-add packages as per current.html: # pkg_add -z -l /root/pkg_list_manual # pkg_add -za -l /root/pkg_list_full 13. Maybe reboot once more to get everything running as it were, i.e. verify that it does. So, that's it. What could possibly go wrong! Well, maybe try this once in a local VM, first ... the practice helps. Moritz
Re: bsd cloud
> i have seen, some minutes ago, a message about cloud with BSD! > I have seen announcements on cloud computing every where. What is the > difference between a BSD cloud and a linux cloud ? A windows cloud and a > linux cloud ? > Isn't all that the new buzz word in the market ? It's bullshit marketing blah-blah if the "cloud" cannot be automated, i.e. it must be possible to provision new RAM and CPU resources with an API. In fact, it's all about APIs ... the OS defines the APIs available to access those RAM and CPU resources (most significant difference would be Windows vs Unix). It's all about abstraction of the infrastructure, and automation. As a user, I don't care if my API calls manage virtual machines or force an intern to timely do everything manually on bare metal for me, using jolts of electricity. That's also what makes it potentially interesting -- just not from a security point of view. In case of virtualization, the guest OS (possibly OpenBSD) can never be any more secure than the host OS (usually Linux), and the whole setup is more risky overall due to added complexity and additional attack vectors. On the plus side, the things one can build with an infrastructure that can be 100% automated are quite cool, at the very least in terms of auto-repair (covering most types of failures) and the hyped auto-scaling. > So what would a BSD cloud be different in the context of cloud (not openbsd > features) ? Different long- and short-term maintenance, I would say (in my experience with OpenBSD, better + cheaper than Linux). And, with OpenBSD as the guest, I would also expect significant benefit wrt security: due to its nature in general, and lack of unnecessary complexity in particular. From a dogmatic point of view, however, OpenBSD "in the cloud" is not desired (due to the security issues wrt virtualization). IOW, I'd also be very much interested in a proper compute cloud offering OpenBSD instances, ideally with an EC2-compatible API ... it would be an improvement. > So in essence what is it really cloud we have not doing since networks have > been in the game ? > Don't take this as an offense, i just cannot understand all this frenesy > about clouds ... Automation. 42. Many people seem to mix up cloud computing with plain virtual servers, grid computing, clustering, whatever ... but those are just possible components, and what it boils down to is abstraction and automation -- at least from an engineering point of view. Moritz
Re: OpenSSL handling intermediate certificates
Moved from tech@ to misc@ ... On 08/09/12 06:27, Justin N. Lindberg wrote: > I do believe this would allow me as a client to validate certs signed > by the intermediate certs with no problem, and in fact I seem to recall > actually doing the same thing before with self-signed certs for my own > use, but my hesitation with this method is that those intermediate > certs will then be trusted unconditionally, since I've just promoted > them to root status by appending them to /etc/ssl/cert.pem. I thought You always put trust into the whole chain (that's why you need intermediate certs in the first place), starting with your trusted root. If that trust turns out to be misplaced in any one of the components (root, intermediate, server), you lose. Here, implicit trust is just as strong as explicitly trusting a single server certificate. The latter provides maximum control (trusting only a single chain instead of many), but becomes infeasible quickly. It's a trade-off, and it's good to make an informed decision based on the application requirements. Then you know what risk you're actually accepting, and why you do it. Moritz
Re: IPv6 woes: gateway on different subnet
Hi Lukas, > # HIER ist der Pudel begraben ;-) You need a local IP in the subnet > # of the gateway. > > inet6 alias 2a01:4f8:120:70c0::2 59 Gilles' solution of using (in your case) inet6 alias 2a01:4f8:120:70c1::1 59 instead of inet6 alias 2a01:4f8:120:70c1::1 64 has less potential for mayhem and does not require you to use an IP from a range that does not belong to you. ;) It's enough to use the 59 prefixlen on only one of the v6 aliases. I'll be using this "solution", too, until the dedicated route to the gateway works. > # ... > # Since the gateway is reachable now, we specify the default route. > !route add -inet6 default 2a01:4f8:120:70c0::1 FYI, /etc/mygate can handle the 2nd default route for IPv6 just fine. Moritz
Re: IPv6 woes: gateway on different subnet
Hi Gilles, > I have a server at hetzner too, after battling for a while I gave up > and resorted to a hack -> setting up your interface to have the same > netmask as the gateway. > > Dirty, but works.. OK then, good to know that this also works. Thanks. I suppose I'll resort to that, too, if no proper solution can be found. Considering that it is said to be working for all those OtherOSs, including FreeBSD and various Linux spawn, I'm wondering if we have a bug here. If someone could confirm that ... >> # route add -inet6 -iface -ifp re0 -net 2a01:4f8:110:4360:: -prefixlen >> 59 2a01:4f8:110:4360::1 >> # route add -inet6 default 2a01:4f8:110:4360::1 ... *should* work, I can confirm that it doesn't, and file a PR if that helps. At least that way it isn't forgotten. Moritz
Re: IPv6 woes: gateway on different subnet
Hi Todd, > Have you tried ping6 -n ff02::2%re0 ? Does anyone respond? Try using > the respond(ers) as your IPv6 default gateway. > > Link local is best for IPv6 gateways for various reasons, if your upstream > isn't picky (unlike he.net tunnels, for example). Awesome, this almost works! :-) When doing it like that, I get to replace the inet6 default route with an fe80::...%re0 address, and to remove the "-inet6 -iface -ifp re0" route altogether. Afterwards, I have full -- but temporary -- IPv6 connectivity. This setup does not survive a reboot. It is strange, but only *after* ping6ing ff02::2%re0 I get to use the responder as a gateway. I assume this is because until then, it's not in the ndp table. So ... ping6 would have to become part of my networking setup. Huhhh. This is also completely against upstream's documentation, as these fe80 gateway addresses might be subject to change. I guess, for all intends and purposes, my upstream is picky and I'm really supposed to use the public IPs. Is there a reason why # route add -inet6 -iface -ifp re0 -net 2a01:4f8:110:4360:: -prefixlen 59 2a01:4f8:110:4360::1 # route add -inet6 default 2a01:4f8:110:4360::1 does not work (as opposed to the equivalent in IPv4)? Thank you, this already was a huge step forward for me. Moritz > | The IPv6 network is supposed to be 2a01:4f8:110:4363::/64, the gateway > | is 2a01:4f8:110:4360::1/59.
Re: IPv6 woes: gateway on different subnet
Hi, > Have you tried pinging the local interface first? Does ping ::1 works? > Then does ping fe80:xxx (replace by output of your interface) works? > etc... Ping6ing those two works. >> The IPv6 network is supposed to be 2a01:4f8:110:4363::/64, the gateway >> is 2a01:4f8:110:4360::1/59. So again there's the aliases in >> /etc/hostname.re0 ... > > Can you ping the gateway? Nope. Not from the server, anyway ... I can ping6 it here from home through my 6in4 tunnel. > Also, showing us a full ifconfig might be good. Here you go. The unabridged ifconfig re0 output: re0: flags=8843 mtu 1500 lladdr 00:1d:92:39:57:54 priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet 78.46.41.142 netmask 0xffe0 broadcast 78.46.41.159 inet6 fe80::21d:92ff:fe39:5754%re0 prefixlen 64 scopeid 0x1 inet 78.47.124.161 netmask 0xfff8 broadcast 78.47.124.167 inet 78.47.124.162 netmask 0xfff8 broadcast 78.47.124.167 inet 78.47.124.163 netmask 0xfff8 broadcast 78.47.124.167 inet 78.47.124.164 netmask 0xfff8 broadcast 78.47.124.167 inet 78.47.124.165 netmask 0xfff8 broadcast 78.47.124.167 inet 78.47.124.166 netmask 0xfff8 broadcast 78.47.124.167 inet6 2a01:4f8:110:4363::2 prefixlen 64 inet6 2a01:4f8:110:4363::3 prefixlen 64 inet6 2a01:4f8:110:4363::4 prefixlen 64 inet6 2a01:4f8:110:4363::5 prefixlen 64 inet6 2a01:4f8:110:4363::6 prefixlen 64 inet6 2a01:4f8:110:4363::7 prefixlen 64 inet6 2a01:4f8:110:4363::42 prefixlen 64 >> inet6 alias 2a01:4f8:110:4363::42 64 > > How did you assign this? Did they or did you? I did, via ifconfig/hostname.if. All of this requires 100% manual configuration. >> !route add -inet6 -iface -ifp re0 -net 2a01:4f8:110:4360:: -prefixlen 59 >> 2a01:4f8:110:4360::1 > > Same question here, if they are using ra, i doubt your routing > gateway will actually be 2a01, more likely to be fe80: If by ra you mean rtadv, i.e. router advertisement, they're explicitly not using/offering it. > Start with internal diagnosis first, then worry about reaching the > outside world. Heh. :) Well, yeah. Purely local IPv6 works, and the sane tunnel setup I have here at home does, too. > Try this: tracepath6 2a01:4f8:110:4360::1 Not sure what that is, but traceroute6 has no chance on mrsserver. The interface-bound route seems to be defunct. Again, works fine through my home tunnel. Thanks for looking into this. Moritz
Re: IPv6 woes: gateway on different subnet
Additional information I forgot previous writeup: at some point in the current setup, the kernel complains. I have one additional line in my dmesg nd6_rtrequest: bad gateway value: re0 Googling this didn't steer me in the right direction. It's also the only error message I'm getting here. Moritz
IPv6 woes: gateway on different subnet
Hi, after a couple of days of running into dead ends, I would appreciate some help. To summarize: For more than 3 years I'm successfully running OpenBSD (it's now at OPENBSD_4_9/i386, running GENERIC.MP) at the German hoster Hetzner as my expensive little plaything. They offer native IPv6 for some time now, and I want to use it. However, the same methodology used with IPv4 does not work with IPv6 and I just can't figure out why (it's supposed to work identically.) The working IPv4 setup: Additional network is 78.47.124.160/29, the gateway is 78.46.41.129/27. In /etc/hostname.re0 is the aliases and the route to the gateway of that network: inet alias 78.47.124.161 255.255.255.248 78.47.124.167 [...] !route add -inet -iface -ifp re0 -net 78.46.41.128 78.46.41.129 -netmask 255.255.255.224 I set the default gateway 78.46.41.129 in the first line of /etc/mygate. This works: $ ping -I 78.47.124.161 www.google.com PING www.l.google.com (74.125.77.147): 56 data bytes 64 bytes from 74.125.77.147: icmp_seq=0 ttl=56 time=16.943 ms [...] The IPv6 setup (broken): The IPv6 network is supposed to be 2a01:4f8:110:4363::/64, the gateway is 2a01:4f8:110:4360::1/59. So again there's the aliases in /etc/hostname.re0 ... [...] inet6 alias 2a01:4f8:110:4363::42 64 [...] !route add -inet6 -iface -ifp re0 -net 2a01:4f8:110:4360:: -prefixlen 59 2a01:4f8:110:4360::1 The second line in /etc/mygate sets the IPv6 default gateway 2a01:4f8:110:4360::1. This does not work: $ ping6 ipv6.google.com PING6(56=40+8+8 bytes) 2a01:4f8:110:4363::42 --> 2a00:1450:8005::68 ping6: sendmsg: No route to host ping6: wrote ipv6.l.google.com 16 chars, ret=-1 A look at the routing table shows various differences between IPv4 and IPv6. Again, the working IPv4 entries first: default 78.46.41.129 UGS 19 6792145 - 8 re0 78.46.41.128/27 link#1 UC2 0 - 4 re0 78.46.41.128/27 link#1 UCS 0 0 - 8 re0 78.46.41.129 00:26:88:76:21:1b UHLc 1 0 - 4 re0 78.46.41.142 00:1d:92:39:57:54 UHLc 0 6 - 4 lo0 78.47.124.160/29 link#1 UC0 0 - 4 re0 78.47.124.161 127.0.0.1 UGHS 097 33200 8 lo0 (.142 is the main IP of mrsserver.net) As can be seen, everything resolves nicely ... by comparison, IPv6 looks fubar'd: default 2a01:4f8:110:4360::1 UGS 0 11 - 8 re0 2a01:4f8:110:4360::/59 2a01:4f8:110:4360::1 US 1 0 - 8 re0 2a01:4f8:110:4363::/64 link#1UC 0 0 - 4 re0 2a01:4f8:110:4363::42 00:1d:92:39:57:54 HL 0 0 - 4 lo0 That's it, nothing else from these networks, and the local host route for ::42 isn't even (U)p. ndp -a shows: Neighbor Linklayer Address Netif ExpireS Flags 2a01:4f8:110:4363::42 0:1d:92:39:57:54 re0 permanent R fe80::21d:92ff:fe39:5754%re0 0:1d:92:39:57:54 re0 permanent R fe80::1%lo0 (incomplete) lo0 permanent R I tried to use ndp -I to set the default IPv6 interface to re0, but what that does is change the behavior of ping6 from EHOSTUNREACH to 100% packet loss. After doing so, the gateway shows up in ndp: 2a01:4f8:110:4360::1 (incomplete) re0 permanent I ... and that's as far as I have come. I also tried to solicit router information after setting net.inet6.ip6.accept_rtadv to 1, but there's nothing like that on the wire. I have to do manual configuration. Lastly, the host's pf.conf is family-agnostic in almost all parts (and the two remaining places have been triple-checked.) It's also creating state for all outgoing traffic, so it really shouldn't interfere. What I haven't pursued, yet, is that Hetzner configured my network wrong. This is hard to believe, though, as getting an IPv6 subnet from them is 100% automated and a problem would probably affect all their customers. I'm stumped. What have I missed? Any and all help is greatly appreciated! Thanks, Moritz
Re: Skype on OpenBSD 4.1 using Fedora RPM
Siju George wrote: Call Failed : Problem with audio playback It is unlikely that Skype will ever work on OpenBSD for more than chatting, as it uses ALSA for audio output (same as Flash 9.) That's not something compat_linux(8) can handle, only OSS audio output is emulated. Moritz
Debugging an OpenBSD/vax-only resource leak
Hi, a strange issue is affecting the system monitor I wrote. It's working fine everywhere (i386, sparc*, amd64, other OSes on various archs), except on OpenBSD/vax (-current snapshot as of Jan 5th, same with 4.0-release) running inside simh-vax. It leaks huge amounts of memory there, and CPU usage is rising over time as well. I have no idea how to debug this, and whether this is even related to my code or not (AFAICT the problem could be anywhere, my bug, g++ bug, libstdc++ bug, libxml2 bug, simh-vax bug, ... probably specific to the combination VAX + a.out + static libs.) Is there a way to investigate this? I fear that practical ways are slim; the VAX simulation is also incredibly slow, making almost everything seem to take forever. Any hints would be highly appreciated. Moritz
Re: -current change affects video playback
Christian Weisgerber wrote: This is weird. Some change to -current between ~Dec 22 and ~Jan 8 has caused video playback (mplayer playing DivX with the xv driver) on my Thinkpad X40 to become headache-inducingly jerky. mplayer itself is not aware of the problem, it doesn't report a low frame rate. - It's in the kernel. Simply going back to my old kernel (Dec 22) makes the problem go away. - It isn't the sys/dev/pci/agp.c changes. Does anybody else see this? I see it as well, although the jerkyness is only noticable here, not headache-inducing (IMO, on an AMD 2600+ with a Geforce FX6600.) Admittedly, I didn't look into this issue, so I can't comment further on the reason(s). Moritz
Re: difference between macros and tables in pf
Artyom Goryainov wrote: Is any difference when to use macros or tables if there is no need in storing many adresses My suggestion is that you use whatever is easier for you to maintain. The break-even point between tables and macros was somewhere around 5-8 addresses, IIRC, where a small number of occurrences like this won't make up much of a performance difference. Moritz P.S.: The exact numbers are in the pf mailing list's archives, in a mail from [EMAIL PROTECTED]
Investigating struct if_data.ifi_link_state
Hi,
not long ago, duplex information was added to if_link_state. Today, I
took a closer look and it looks like my
sk0 at skc0 port A, address 00:11:95:ff:28:1d
eephy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 3
does not set it to > 2, even though SIOCGIFMEDIA's output contains
IFM_FDX ("full-duplex"). So the driver probably knows about this
information already ... Is not setting if_link_state "properly" on
purpose? Or is it work in progress and will it change later? Did I find
a buglet?
Moritz
RFC on XMLSysInfo, and Thanks for the joyride!
Hi, many moons ago, I mentioned the system monitor I wrote in some thread here on misc@, as it was possibly useful for someone then. I continued working on it, and it has come a long way since. Initially written on and for OpenBSD, it now also runs on FreeBSD, NetBSD, Linux, Solaris, and a bit of Mac OSX, too, and also has a whole bunch of new features. Here is XMLSysInfo (aka XSI), including lots of additional information on it: http://xsi.kolabore.ath.cx/ (There's also an OpenBSD port there.) I am now at the point where I would change its "alpha" status to "beta". However, that would also mean "no new features" and "only important bug fixes for the XML Schema allowed". Because of this, I am making this request for comments and feedback. If you're interested in a system monitor like XSI, please check it out and let me know if there's some feature that you'd need, and whether you can find inconsistencies or something that seems illogical in the output or the schema. Your help (and, of course, any other kind of feedback as well) is very, very much appreciated. Please be so kind to not bother this mailing list with replies to the off-topic parts of the mail. Now ... So I wrote a system monitor, and ported it to a bunch of operating systems. This means, I got to learn and deal with a lot of kernel<->userland APIs. Almost every OS had few or more parts that were fun to implement. In that regard, OpenBSD clearly stands out as the pure-fun operating system, with no "nasty surprises" whatsoever. After years of using OpenBSD, I became spoiled of how everything Just Works, and started to take all the goodness for granted. My recent programming, however, reminded me of why I actually like OpenBSD -- the consistency, excellent documentation, and ease-of-use is everywhere[1], including API-land. There was no half-baked crap to be found, and what I wrote was immediately architecture-independent. Thanks for the joyride! [1]: For various meanings of "everywhere". As in "most" and "all important" areas. A year ago, I stumbled a bit through PPP-related code in both kernel- and userland ... that was irritating. Or, in retrospect, looking at my OpenBSD-specific code, it's boring: sysctl(3) in most places, no kludges ... all the interesting information is readily available. Luckily, it was the first thing I wrote, so it was still very interesting at the time. :-) About the others ... well, here's the list of ports I wrote, ordered by my personal sanity level, from high to (very) low, while writing them (might apply to API quality as well ;-)): OpenBSD FreeBSD (*) Solaris NetBSD (*) Linux (*) means that I was surprised by the result. Enough praise for OpenBSD ... there's nits to pick! Boohoo, I need to try and look at an arbitary number of sysctls to get all sensors (I went with 256 like sensorsd(8).) On the other hand, I'm pretty sure that doing it like this simplyfies a lot of other code, so all is well. Still, a HW_SENSORS_NUM sysctl would be nice to get the number of sensors that I should try to read. That, and ... hm, nothing. The code to get the default routes looks scary, but that's scary everywhere all the same. FreeBSD surprised me a bit, as I expected it to be quite different. Turns out it actually is different, but most things (at least those it actually supports) were pretty easy to do. Only mild inconsistencies wrt reading the CPU frequency, and, like on OpenBSD, I can get all that stuff while being confined in a chroot with minimal privileges. Solaris doesn't have sysctl(3), but a comprehensive sysinfo() that helps. The ioctl(2) stuff about networking stats is crazy and complicated. Fortunately, talking to the kernel directly isn't needed in most other cases, as there are some libraries for this kind of stuff that have well thought-out and properly documented APIs. On the other hand, what these libraries actually return seems to be neither standardized nor documented anywhere. There's some guesstimating going on, so I'll have to see how that port fares over time ... On Solaris, it is impossible to be chroot()'ed as a system monitor like XSI. Oh, and heed the warning about "evolving" APIs. They like to make really pointless changes to them between releases. NetBSD was rather disappointing, from my point of view. Thanks to the common heritage with OpenBSD, some copy+paste was possible. Where they diverged over the years, things get "interesting". Being able to get the CPU frequency depends both on the architecture and whether one or another LKM is loaded. Then, there's that weird "security feature" that the kernel seems to actively hide insensitive information about filesystems mounted outside the chroot. That's nonsense, and means that I can't chroot() here, either. Enter the big, non-backwards compatible API changes between releases wrt disk I/O. This shall be forgiven, however, since the old structure and sysctl n
Re: Web access to sysctl hw.sensors
Douglas Maus wrote: I'd like to be able to remotely observe my server's hardware health. I recently wrote something that might help achieve what you want. It's a bit of a poor-man's SNMP with a slightly different target audience. It's still "alpha", but the documentation is complete, making it usable ... I think: http://xsi.kolabore.ath.cx/ Only OpenBSD 3.9 and newer are supported, and it depends on textproc/libxml. Any feedback would be highly appreciated. and I'd like to check on my RAID status with $sudo raidctl -s raid0 XSI can't do that, yet ... looks easy enough to implement, though. For that to work, xsi would have to be a member of the operator group, however. I'll think about this, and how it should show up in the grammar. Moritz
Silly^WFantastic OpenBSD promo video!!
Hello! I made something ... and for some reason, several people liked it enough to help it spread at reckless torrent speeds! http://jolly.kicks-ass.org/OpenBSD_install-quick.avi.torrent should get you started, and with the friendly help of Nicholas Marriott -- who said he'll keep the tracker running for about a week -- it should be there in no time. Be warned, it's horribly geeky. There are people who will have no understanding, whatsoever, for this. Yep, it was good revenge on the flatmate for making me bring out the trash! (Most of it was his!!1) Others may appreciate it a lot, so if you select your audience well, this could be a special advocacy tool. ;) Please direct comments, flames and praise to me directly and don't bother the list with them. Other than that, feel free to do whatever your wish with that video, it's officially in the public domain, trademarks belong to their respective owners, yadda yadda blah. Moritz
Re: Icecast defaults
Karel Kulhavy wrote: The icecast.xml.dist in Icecast is containing nonexisting directories - maybe it's intended for the user to fill in, maybe it's just forgotten. The way it is right now is intended, see /usr/local/share/doc/icecast/README.OpenBSD Yeah ... I'll fix the grammar in the first paragraph with the next update. ;-P As the package MAINTAINER, I'm supposed to answer questions like these. Feel free to mail me directly, instead of the lists. In case a package has no MAINTAINER, ports@ is the appropriate list. Moritz
Re: latest sendmail patch
Monah Baki wrote: I'm trying to apply the latest patch for sendmail and on my "make", I get the following error: [...] OpenBSD 3.9-current (GENERIC) #685: Mon Apr 10 14:00:41 MDT 2006 Something is quite weird with your system. Try to run either -current, -release+patches or -stable (the latter two would be painful and unsupported downgrades in your case; a reinstall would make sense, I guess), and not a mix of different versions. It's what the FAQ calls "being out of sync" on several occasions, and it's lots of trouble. Moritz
Re: cruxports for OpenBSD
Siju George wrote: there is a software called foo suppose 3.9 installs foo.1.1.1 if you use ports. now a few security holes are found in foo.1.1.1 So the foo developers release foo.1.1.2 And the foo developers *strongly encourage* everybody running foo.1.1.1 to upgrade to foo.1.1.2 as soon as possible. So what is the best wat to do it in the present ports system? Update your ports tree to its respective -stable version and install foo-1.1.2 (or foo-1.1.1 + patch ~= foo-1.1.1p0) from there. If it's among the official packages collection, get foo-1.1.2.tgz/foo-1.1.1p0.tgz from your favorite FTP mirror's .../OpenBSD/`uname -r`/packages/`arch`/ directory, since updated packages are made available there as well. (Just set PKG_PATH and pkg_add -u.) Though I haven't read it in a while, I am sure the FAQ has tons of useful things to say about all this. If, for some reason, there is no security update for foo available, yet, letting foo's MAINTAINER (or ports@, if necessary) know that you're actually a concerned foo-user will speed - or at least clear - things up (all the work is done by regular humans, not robots ;P). Security updates and fixes make it into -stable, regular updates do not. Using -stable packages/ports instead of manual or alien updates has the advantage that these updates are also tested with their respective OpenBSD release, work with pkg_add -u, have their dependencies properly registered, can be un-/re-installed, don't conflict, i.e. come with the whole shebang. Moritz
Re: Bad RAM (?) and freezes
Stuart Henderson wrote:
You missed the dmesg..
Sorry. Here it is, though I don't believe it really makes a difference.
The messages come from the kernel, 3.9-current (GENERIC), though they do
not end up in the dmesg buffer like other "blue" kernel messages. The
logs come from /var/log/messages.
OpenBSD 3.9-current (GENERIC) #590: Mon Apr 17 20:58:47 CEST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(tm) processor ("AuthenticAMD" 686-class, 256KB L2
cache) 1.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real mem = 536440832 (523868K)
avail mem = 482459648 (471152K)
using 4278 buffers containing 26923008 bytes (26292K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(c0) BIOS, date 06/24/02, BIOS32 rev. 0 @ 0xfb470
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 70102 dobusy 1 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0xb8f8
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfde30/160 (8 entries)
pcibios0: PCI Exclusive IRQs: 10 11 12
pcibios0: PCI Interrupt Router at 000:07:0 ("VIA VT82C596A ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x4000! 0xcc000/0x800 0xcd000/0x2200
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "VIA VT8363 Host" rev 0x03
ppb0 at pci0 dev 1 function 0 "VIA VT8363 AGP" rev 0x00
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "VIA VT82C686 ISA" rev 0x40
pciide0 at pci0 dev 7 function 1 "VIA VT82C571 IDE" rev 0x06: ATA100,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 114473MB, 234441648 sectors
wd1 at pciide0 channel 0 drive 1:
wd1: 16-sector PIO, LBA48, 117800MB, 241254720 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 5
wd2 at pciide0 channel 1 drive 0:
wd2: 16-sector PIO, LBA48, 117800MB, 241254720 sectors
wd3 at pciide0 channel 1 drive 1:
wd3: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd2(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 5
wd3(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 5
uhci0 at pci0 dev 7 function 2 "VIA VT83C572 USB" rev 0x16: irq 11
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
viaenv0 at pci0 dev 7 function 4 "VIA VT82C686 SMBus" rev 0x40
vga1 at pci0 dev 8 function 0 "Matrox MGA Millenium 2064W (Storm)" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
fxp0 at pci0 dev 10 function 0 "Intel 8255x" rev 0x08, i82559: irq 10,
address 00:02:b3:26:b8:40
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
pciide1 at pci0 dev 11 function 0 "HighPoint HPT302 IDE" rev 0x01: DMA
pciide1: (null) ignored (disabled)
pciide1: using irq 11 for native-PCI interrupt
wd4 at pciide1 channel 1 drive 0:
wd4: 16-sector PIO, LBA48, 157066MB, 321672960 sectors
wd5 at pciide1 channel 1 drive 1:
wd5: 16-sector PIO, LBA48, 157066MB, 321672960 sectors
wd4(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5
wd5(pciide1:1:1): using PIO mode 4, Ultra-DMA mode 5
skc0 at pci0 dev 12 function 0 "D-Link Systems DGE-530T" rev 0x11,
Marvell Yukon (0x1): irq 10
sk0 at skc0 port A, address 00:13:46:99:38:6a
eephy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 3
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
biomask fb65 netmask ff65 ttymask ffe7
pctr: user-level cycle counter enabled
mtrr: Pentium Pro MTRR support
dkcsum: wd0 matches BIOS drive 0x80
dkcsum: wd1 matches BIOS drive 0x81
dkcsum: wd2 matches BIOS drive 0x82
dkcsum: wd3 matches BIOS drive 0x83
dkcsum: wd4 matches BIOS drive 0x84
dkcsum: wd5 matches BIOS drive 0x85
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
Apr 22 12:45:02 phoenix /bsd: Data modified on freelist: word 3 of object 0xd1429030 size 0x10 previous
type packet tags (0xdeadbee7 != 0xdeadbeef)
Think I've seen this with some wireless drivers.
Nothing wireless in that box. In any case, this very much looks like a
slow death of the RAM sticks to me. Shops close in about 30 minutes from
now, so I mostly wanted to make sure that I'm not missing another
important possibility here.
Stuart, there's something weird about your MTA/DNS wrt delivering your
mail directly to me. It arrived, but only as a bounce from aries.oic.lv:
Reporting-MTA: dns; aries.oic.lv
X-Postfix-Queue-ID: 5CBAC23461
X
Bad RAM (?) and freezes
Hi, my assumption is seriously busted RAM: Apr 22 12:45:02 phoenix /bsd: Data modified on freelist: word 0 of object 0xd1429030 size 0x10 previous type packet tags (invalid addr 0xd14a7350) Apr 22 12:45:02 phoenix /bsd: Data modified on freelist: word 3 of object 0xd1429030 size 0x10 previous type packet tags (0xdeadbee7 != 0xdeadbeef) Apr 22 12:45:02 phoenix /bsd: Data modified on freelist: word 0 of object 0xd1429030 size 0x10 previous type UVM amap (invalid addr 0xd14e0ff0) Apr 22 12:45:02 phoenix /bsd: Data modified on freelist: word 3 of object 0xd1429030 size 0x10 previous type UVM amap (0xceadbee7 != 0xdeadbeef) Apr 22 12:45:02 phoenix /bsd: Data modified on freelist: word 0 of object 0xd1429030 size 0x10 previous type UVM amap (invalid addr 0x51461f10) Apr 22 12:45:02 phoenix /bsd: Data modified on freelist: word 3 of object 0xd1429030 size 0x10 previous type UVM amap (0xdeadbe6f != 0xdeadbeef) Apr 22 12:45:02 phoenix /bsd: Data modified on freelist: word 3 of object 0xd1429030 size 0x10 previous type UVM amap (0xceadbee7 != 0xdeadbeef) Can someone please confirm or give me a hint about what else could be wrong? Thanks a lot, Moritz
Re: pf blocking nets in a way like *.google.com ?
Lars Hansson wrote: Why isn't it feasible to use Googles allocated netblock (216.239.32.0/19)? Because there's nothing that says that every *.google.com site has to be within a block allocated to Google. Duh. The obvious solution is to have pf make a DNS lookup on each and every packet that arrives. Moritz
Re: Sendmail security problem
Zoong PHAM wrote: Do you mind to share the instruction of how to replace OpenBSD's sendmail with sendmail.org's 8.13.6? Just forget about that administration nightmare and go either -stable or -current. Not sure whether this warrants and errata entry (too much hype for my taste), but if it does, there'll be a patch there eventually, too. Moritz
Going nuts with wireless (ath(4) in this case)
Hello, today, I wasted tons of money (from my perspective) ... First, I bought a D-Link DWL-G650. Turns out it was revision C with an AR5213 on it ... the driver complained about the RF radio not being supported. After lots of whining in the store, I got to replace it with a Netgear WG511T. Before breaking any seals of the packaging, I called Netgear tech support to ask for what they built into this card, with s/n foo-blah-bar. Turns out they couldn't tell, really, so I asked whether there are any different revisions of that card, i.e. whether it ever changed. They say "no, it's been always the same" and I figured that was good enough. Oh well, I thought wrong. Same AR5213, same unsupported RF radio. ARGH! No way I'm going to be able to get this one replaced, with broken seals in the package. It seems that it's virtually impossible to get a working/supported wireless card these days ... damn those vendors who change hardware without notice, and damn Netgear for lying to me. :-(( And not to mention that useless, new wireless bridge that is doing nothing ... at least it has 3 shiny blue LEDs. Now I figured, what the hell; let's try and make it supported. My wishful thinking and simply cranking the supported revisions of ath(4) allowed the driver to attach, but that's as far as it goes. I can mess around with ifconfig, setting any channel other than 6 isn't possible and I'm getting "this should not happen"-errors. Since I was too stupid to save the kernel output earlier, it's now garbled ... impressive, how stuff in memory survives power-cycles in dmesg (all the numbers are okay, otherwise I wouldn't bother pasting this:) "A4heros C/mmunications, In\M-c., AR5001--, Wireless LAN Reference Card" : irq 11 ath0: AR5213 7.9 phy 4.5 rf2112a 5.6 FCC2A*, address 00:0f:b5:ef:5e:a0 ath0: device timeowt ar5k_ar5212_nic_wakeup: failed to resume |he AR5212 (acain) avh0: Unable to reset h\M-ardware; hal status 3671035180 ath0: device timeowt [...] :-) My experimentation did some weird stuff to OpenBSD, which is why I'm running a sane kernel again. Anyways, I'm obviously not getting anywhere, and driver hacking still is a closed book to me. However, I'm quite interested in learning more, or at least try and help someone who's further down this road by testing patches etc. In case I'm alone with this, I'd highly appreciate some pointers on how to get started. I don't remember, was Atheros a nice or an evil company? How can I get the information I need to get this to work? Thanks for your time, Moritz
Re: web FAQ 15 correction?
Will H. Backman wrote: Possible correction? http://openbsd.org/faq/faq15.html#Intro "Invoking pkg_add(1) with the -u flag and no package name will just examine all installed packages for updated versions. When a package has dependencies, they are also examined for updates." "pkg_add -u" now also does the upgrade, doesn't it? The FAQ follows the latest release, which is still 3.8. Moritz
Re: Snapshot and network connections trouble
Bjvrn Ketelaars wrote: Last week (January 24, 2006) I updated our gateway to snapshot (i386). Everything seems to work fine except that users are complaining about internet-connections being dropped. The main complaint is that it is possible to use the internet but it is not possible to transfer files. I checked this complaint, and indeed there are some problems best described as connections being closed to fast. As a test I reverted to a backup (Snapshot December 29, 2005) which solved the dropping of connections. Is there anyone who recognizes this problem and maybe has a solution? [...] pass in on $wan_if inet proto tcp from ! to 10.0.0.100 port 5000 flags S/SA synproxy state pass in on $wan_if inet proto udp from ! to 10.0.0.100 port 5000 keep state pass out on $wan_if proto tcp from any to ! modulate state flags S/SA [...] It looks like this could be related to modulate/synproxy state being currently broken: http://marc.theaimsgroup.com/?l=openbsd-pf&m=113844738811816&w=2 It would be interesting to know if the patch helps, I suppose? Moritz
Re: patch management on larger install bases
Russell Fulton wrote: I am just starting to upgrade all my obsd boxes to 3.8. I have a copy of the official CDs -- I know the the ISOs are copyright but is there a way of burning an updated set so I don't have to patch each system individually? Alternately, with the kernel I'm guessing I can replace /bsd (and /bsd.rd) using the little shuffle recommended in the upgrade docs. Which perl files need replacing? How do others who manage several boxes apply patches like the recent ones? One possible way is to set up a -stable build box, and make release(8)s ... so it's just a matter of copying kernels and untarring the relevant install sets on the various boxes similar to how it is outlined on the faq/upgradeXY.html pages. Updating /etc is not necessary in this scenario, so it's really simple. Moritz
Re: How Do I Get snprintf(3) to Return -1?
Theo de Raadt wrote:
I'm having trouble making snprintf return -1. I've tried stuff like:
len = snprintf(str, 0, "%.-Z\n", 9);
printf("%d", len);
but that just prints `2'. Does snprintf ever return -1?
The "new" snprintf() returns -1 on ``output or encoding error'', as was
explained. Luckily, that's almost always the case in relatively recent
Unix-land (where currently available.)
The "old" one, including the one in MS Windows (just in case you need to
be very portable (painful)), always returns -1 on error or truncation --
i.e. you can't use it to count the chars that would've been written if
enough space was available on those systems. At least Windows offers
_vscprintf() to count chars, but well ... *blegh*. Just in case you ever
feel like re-implementing a poor-man's (but portable) asprintf() for
something with vsnprintf().
Anyways, just felt like sharing this, since I've been digging in this
stuff for a while recently. :-/
You must check for either ret > buflen or ret == -1 being a failure
condition.
Or, if you don't care about the destinction between truncation and
encoding/output error, you can check for (ret < 0 || ret > buflen),
which takes care of the unlikely case of snprintf() overflowing its
return int. Or do both. Just in case ... like, some freak accident when
a >2GB string might be supplied to you. ;P
Moritz
Re: Greylisting google's gmail servers
Joseph C. Bender wrote: Instead, I suggest to use a ``no rdr'' line after rdr'ing those in the blacklists to spamd. Actually, yes, because it makes your filter rulesets easier to parse visually, but you want the "no rdr" *first*. This is the configuration that we are using. Uh well, to each his own -- in my case, spews1 hasn't caused any false positives, yet. When I whitelist someone like Gmail and it shows up in SPEWS1 eventually, I really need no more mail from @gmail.com accounts. (Personal choice, and according to the SPEWS FAQ I *should* be doing well with it.) Spam filtering needs to be done individually up to a certain point, so here we have two suggestions, both legitimate. Those who are following any of this advice should know/learn what they're doing and then make a decision (possibly after some testing) according to their needs. Moritz P.S.: Another table with another no rdr line in front with the "I really need mail from these guys no matter what"-IPs and netblocks is still an option. ;-)
Re: Greylisting google's gmail servers
Nick Ryan wrote: We have a problem getting mail from gmail through spamd. Google's gmail public mail service use a large number of smtp servers. The first time In addition to that, they also appear to be retrying either too fast or too slow ... *sigh* rdr pass on $EXT_IF inet proto tcp from to any port 25 -> 127.0.0.1 port smtp <== add this line rdr pass on $EXT_IF inet proto tcp from to any port 25 -> 127.0.0.1 port 8025 rdr pass on $EXT_IF inet proto tcp from ! to any port smtp -> 127.0.0.1 port 8025 Instead, I suggest to use a ``no rdr'' line after rdr'ing those in the blacklists to spamd. /root/whitelist.txt: 216.239.32.0/19 #gmail servers From my point of view on the Internet, gmail uses uproxy.gmail.com to send mail ... which happens to be in a different network than this (it's all IPs of 66.249.92.192/28, i.e. from their 66.249.64.0/19 netblock.) Moritz
Re: C Compiler cannot create executable
Reza Muhammad wrote: "C Compiler cannot create executable" ? what does it mean ? It can mean a lot of things, and since this looks like a message from a configure script, it might be the same issue that happened to me once. Check your environment variables -- for example, a CPPFLAGS="/usr/local/include" could cause this (should be "-I/usr/local/include"). Typos like that happen ... Clues for what the actual problem is can usually be found in the respective config.log file. Moritz
Re: 3.8 pf.conf question
eric wrote:
On Sun, 2005-12-04 at 11:39:01 -0800, Rodney Hopkins proclaimed...
I was looking at the pf.conf included with 3.8, and with the
addition of the following line:
set skip on { lo }
doesn't the lo part of the following line become redundant:
antispoof quick for { lo $int_if }
It becomes irrelevant; after "set skip," nothing else will be evaluated for
that interface.
No, look at what antispoof expands to:
block drop in on ! lo inet from 127.0.0.1/8 to any
block drop in on ! lo inet6 from ::1 to any
That means "antispoof for lo" filters on all but the lo interface group.
The skipping on lo takes care of the "Caveat:" outlined in the man page,
though... it replaces the previously recommended "pass quick on lo" rule.
Moritz
Re: ftp-proxy upgrade instructions
Camiel Dobbelaar wrote: Using the parameter ``-q "(q_med, q_pri)"'' does not result in any error Your testing is correct. ftp-proxy does not understand the queue() syntax like pfctl does, so only one queue name for now. I understand it now ... the literal "(q_med, p_pri)" is not the same as (q_med, q_pri). Argh, I tricked myself good -- pfctl output looked almost perfect, if it weren't for the seemingly misplaced whitespace I overlooked. ;P Moritz
Re: ftp-proxy upgrade instructions
Moritz Grimm wrote: Using the parameter ``-q "(q_med, q_pri)"'' does not result in any error message, however, I have no proof whether this works or not. Actually, [...] Hm, and while I'm at it ... how can things like these be properly tested and debugged in the first place? Other than making educated guesses with [...] Replying to myself here ... I found out that I can get the rules inserted by ftp-proxy with pfctl -a ftp-proxy/x.y -vvsr and it looks like the queue statements were accepted. However, the ACKs definitely don't end up in q_pri but my default queue (q_def). I compared that to what happens when i use "-q q_low", and indeed, everything ends up there with only one queue name as the argument. Now I'm just a bit confused, but at least I know that maybe, in theory, it could work the way I want. :-) Moritz
Re: ftp-proxy upgrade instructions
(Moved from tech@ to misc@) Camiel Dobbelaar wrote: ftp-proxy in -current has been replaced with a new one that was previously called pftpx. Very nice, thanks! Works as expected and easier to use than the old one. I have one issue, though, which I cannot seem be able to figure out on my own. Using the parameter ``-q "(q_med, q_pri)"'' does not result in any error message, however, I have no proof whether this works or not. Actually, my tests suggest that it does not what I want it to do -- my test should've shown about 60-70 kb/s in the q_pri queue, but all it got was some 1 kb/s trickling from some other states... not a very reliable way of testing, though. Is this supposed to work? If yes, what is the proper syntax? Hm, and while I'm at it ... how can things like these be properly tested and debugged in the first place? Other than making educated guesses with pfctl -vvsq or pftop (which doesn't work well with HFSC, so it's no use in my case), I have yet to figure out how to find out whether a state is using a certain (set of) queue(s) or not. Any insight appreciated a lot! Thanks in advance, Moritz
Re: timekeeping on Soekris net4801 w/ ntpd. 3.8
Alexander Hall wrote: You might be interested in the -s switch of ntpd, which is set by default by rc(8). Not any longer. It was removed again to not tempt people to interrupt the booting process via CTRL+C in case it hangs for the one or other reason. It's easy to add back to ntpd_flags in rc.conf.local, though, for those who want it. Moritz
Re: timekeeping on Soekris net4801 w/ ntpd. 3.8
J Moore wrote: I just installed 3.8 on a Soekris net4801 that's been laying around for a while (unused, unpowered). I noticed after install that time was off by like 5 months, so I set it to within a few minutes of current time/date from the wall clock. I've been checking the logs, and this is what I'm seeing... this has been going on for about 8 hours now. Why is ntpd having to make 60+ second adjustments every 3-5 minutes? It would appear the clock on the Soekris is really BFU. [...] Nov 14 06:30:10 opie ntpd[4133]: adjusting local clock by -91.931803s Nov 14 06:34:22 opie ntpd[4133]: adjusting local clock by -90.983786s [...] Nov 14 08:24:20 opie ntpd[4133]: adjusting local clock by -64.294286s Nov 14 08:27:59 opie ntpd[4133]: adjusting local clock by -63.612736s OpenNTPd is working as expected. It is using adjtime(2) to skew the clock, not set it -- in your case, it is slowing it down until it is synced. Run rdate(8) to speed up the syncing process the hard way (the clock will jump.) Read up on ntpd(8)'s parameter `-s' in case you ever need to set a clock that is way off. Moritz
Re: OpenCVS Questions
J.C. Roberts wrote: I was looking to learn more about OpenCVS, in particular, reading the While OpenCVS isn't ready, yet, reading the contents of the cvs-guide package (located in books/cvs-guide in the ports tree) is very educational. OpenCVS will probably work in similar ways (I haven't tried it, yet.) Moritz
Re: what am I missing? -sparc64
John Brahy wrote: OpenBSD is only available via the CD, you have to buy it. That is what Liar. Buying it helps the project, but it is certainly not a requirement. Moritz
Re: Migration to PF - some questions
Travis H. wrote: Yeah, I neglected stateful matching. I should have said that every packet that has to run the gauntlet of rules, has to run all of them. Not necessarily. Search for "pf" and "skip-steps", something that isn't documented much inside OpenBSD, because it is always on and being done for you. Also, the `-o' parameter to pfctl(8) might be of interest. Moritz
Re: customizing /etc/daily.local
frantisek holop wrote: 30 1 * * * /bin/sh /etc/daily 2>&1 > /var/log/daily .out my problem is, that pfctl's output goes to the terminal and not the log file... If you want both stdout and stderr in /var/log/daily.out, the line needs to read ... /bin/sh /etc/daily > /var/log/daily.out 2>&1 Moritz
Re: FFS File Recovery
Leandro Melo de Sales wrote: I deleted an important file of mine and I really need to recover it, how to do this? I'm using openbsd 3.7 and FFS file system. Shut down the computer in question immediately, take out the harddisk, put it in a separate computer(*), dd the entire disk and then start searching with a hex editor, grep and things like that. If you're lucky, you might be able to piece it back together within a few hours or days. Other than that, feel free to panic and consider this a painful lesson that backups are good and rm(1) is dangerous ... The only other recovery tool I know of is scan_ffs(8), but that one won't help you here. Your filesystem already forgot everything about your important file. Good luck, Moritz *: Do not mount it read-write anymore, anywhere, until you have your copy. At least not the partition with the deleted file.
Re: Lifecycle question
Stephan A. Rickauer wrote: Nick Holland schrieb: There are a lot of measures to how the upgrade process works out. Here are SOME: 1) Frequency (i.e., how often do you need to do upgrades) 2) Difficulty (how much human work is involved) 3) Ugency (when an upgrade is needed, how important is it that it is done *NOW*) 4) Downtime (when you do the upgrade, do you need to do it at 3:00am, or can you do it during production hours?) 5) Flexibility (what cute tricks can you do to make the process simpler, safer, easier, etc.) I agree. Furthermore, one has to distinguish between upgrades of an entire OS release level and patching a running system. The latter is not This is somewhat related to what I wrote earlier -- the severity of "upgrading an entire OS release level" is (with some subjectivity) insignificant compared to what I have seen on other OSes. This is a clear benefit of the short release cycle, and it would be a waste not to use it, e.g. by upgrading only once a year. Consider upgrading an "intrusive patch", i.e. something you might already be used to on other OSes, except that it doesn't happen every month but every six months. I say that, because if you'd choose to do the patching as I do (see Nick's point #5), upgrading is pretty much the same work as patching, with only a few extra steps. The largest part of the procedure is explained in the release(8) man page. To recapitulate, the steps required for upgrading OpenBSD manually are 0. Get the install media: Buy a CD, or download, or make your own release(8) at the appropriate time on a local build box tracking -current 1. Install and boot new kernel 2. Untar install sets 3. Update /etc and /dev 4. Reboot This is quite similar to patching the way I do it, except that it's ok to take a shortcut and /etc and /dev may be left alone: 0. Make a new -stable release(8) 1. Install new kernel (shortcut: it's ok not to reboot here) 2. Untar install sets for x in ; do tar xpfz $x -C /; done 3. Reboot This release(8) stuff is the reason why I highly suggest to have some support infrastructure -- a build machine in addition to test boxes. I am using a few self-written scripts for making releases; bloaty sh stuff from 1.5 years ago -- they work nicely, but aren't fit for wide public release and probably in desperate need of a rewrite. Interested parties may request them, though, and I will give them to anyone who can convince me that (s)he doesn't actually need them (wrt release(8) knowledge.) Anyways, with these scripts, that anyone could just as well write for him- or herself, I start a screen and "come back later" -- two hours later, give or take, I have nice -stable install sets that I can deploy and a bootable install .iso image if I need it. This is lots of work for the computer, and very little to do for me. I estimate some 10 minutes of actual human work, and during the course of following -stable, even more things could be automated than what I currently do. *patching* - only saying that since some posts seem to treat patching and OS upgrade similarly). They *are* really similar, see above. :-) One main reason why companies are interested in 'enterprise products' of vendors like Redhat and SuSE etc. is the five (!) year lifecycle (at least with SuSE, don't know with RH). That means you buy your hardware, install the OS, patch five years and toss the systems afterwards. That As Henning@ is quoted from somewhere in another mail, he has some boxes that were upgraded since OpenBSD 2.7. Those are from more than 5 years ago, and since he even made it through the a.out->ELF change, I can't think of anything that would prevent this from going on another 10 years ... well, except for utter and complete hardware destruction or those boxes becoming too slow for their future purpose(s). Moritz
Re: Lifecycle question
Stephan A. Rickauer wrote: The question is how you OpenBSD guys handle the upgrade issue. From the website I learned that -STABLE is maintained for only one year (= two releases). Given that upgrading by skipping one release is not recommended, does that mean one needs to upgrade the entire OS every half year? I couldn't get that from the website. From my experience, I can say that upgrading is not actually an "issue" with OpenBSD. This can be best explained with one of the catch-phrases that describe it, "OpenBSD constantly evolves, it does not revolutionize all the time." Version numbers are mostly that, numbers, and an indication that several weeks of disciplined quality assurance went into it after another development cycle. The result is really painless upgrades -- maybe not in a sense of (attempted) automation like on some other OSes, but in terms of breakages. The time saved by the fact that everything typically Just Works makes up for the few additional manual steps during upgrades, and Nick Holland is so kind to supply very thorough upgradeXY.html documents for every release, outlining any possible "gotcha"s. There are also several ways to speed up upgrades when dealing with lots of similar boxes, slightly customized `release(8)'s via siteXY.tgz and so on. All in all, it helps to have some support infrastructure to manage an OpenBSD deployment -- e.g. a build box and maybe one or two representative test boxes (although that's good to have with any other OS as well.) As I am writing this, your second mail just came in. With your HA setup, there won't even be any downtime during upgrades, and they will *really* be painless as you probably don't have to deal with any package upgrades. Reboot new kernel, untar sets, apply a prepared patch for /etc, MAKEDEV and mtree, reboot and you're good to go after some 5 minutes, give or take, per box. Of course, simply swapping out harddrives with an upgraded installation is another possibility. Moritz
Re: smstools compile problem
[EMAIL PROTECTED] wrote: "Makefile", line 19: Missing dependency operator "Makefile", line 21: Need an operator "Makefile", line 23: Need an operator Try gmake. Moritz
Re: Where to report package bugs?
Will H. Backman wrote: Where do we report package bugs? Each package has a maintainer that can be contacted (find out with ``pkg_info ''.) In case the maintainer cannot be reached for some reason, the ports@ mailing list is the next instance to turn to. Some packages tell you to go to ports@ directly. OpenBSD ports exist to create packages that can be installed via pkg_add - actually, installing something from ports does the same thing: create package first, then install. Moritz
Re: recover directory!!!
Joco Salvatti wrote: Let's suppose I deleted a directory, but I didn't meant to do that, for example, /usr/bin. Is there any way to recover the contents of this directory? Is there any tool or technique that I could use to recover my lost data? Yeah, it's "restore from backup". Other than that, rm(1) is final. In your example case, you're lucky. You can use the install media to upgrade to the same version you're already running - that'd bring /usr/bin back. Be careful with rm(1), always, and don't rely on non-standard features that make rm ask for confirmation for each file when running as root. Moritz
Re: extracting new login.conf from /usr/src/etc in -current
Todd C. Miller wrote: Is it really so difficult to run mklogin.conf? Actually, it isn't... Sorry, I managed to actively ignore mklogin.conf somehow. Thanks for the pointer. Moritz
extracting new login.conf from /usr/src/etc in -current
Hello, since the switch to generate login.conf, things became quite a bit less comfortable for those following -current "manually"... well, at least for me. Since I stick to defaults whenever possible, /etc updates used to be quite hassle-free -- I'd simply copy over the updated file and be done with it, when possible. That accounts for pretty much everything, except for the user database, rc.local and maybe one or two other things. I was hoping to politely convince TPTB to provide pre-generated login.conf files in /usr/src/etc/etc. in CVS, similar to the MAKEDEV script. Thanks, Moritz
Re: Text editor
Otto Moerbeek wrote: On Sun, 7 Aug 2005, imEnsion wrote: I'm surprised everyone keeps recommending using vi and vim, yet no one has given a pointer on how to learn it. Sure, an OReilly book may come "An Introduction to Display Editing with Vi", /usr/share/doc/usd/12.vi/. This document is the closest thing available to an introductionto the vi screen editor. To learn the basics of vi, vim comes in handy. After installing vim, one can use vimtutor to learn-by-doing all the useful basics in roughly 30 minutes - and those work in our base nvi as well. It is well-written and very effective at teaching vi. Afterwards one is "skilled" enough to appreciate the complete documentation and do any configuration work and/or nvi-based programming on OpenBSD without (further) packages installed. Moritz
Re: suggested /etc/skel/ modifications
[EMAIL PROTECTED] wrote: Ever heart of a multiuser system where one user shouldn't be able to acces the files of another user? Not all users are thinking about this issue and many forget to change the modes for confidential files. IMO, But keeping confidential files on "true" multiuser systems is stupid ... I disagree, How about a heavy build server for different projects? Or shared (insert word)-solutions. You cannot be to careful with your files, one day, as normal user, you will forget to chmod() that file ... Whenever you configure a box like that, you will (have to) put more thought into it in the first place. You cannot assume that a default installation of any general purpose OS, including OpenBSD, can serve each and every possible purpose right out-of-the-box. There has to be done some careful, custom configuration. The cleanliness and lack of nasty surprises in OpenBSD might make this easy (or at least easier) to implement, but the design part is always the same. It's just as with pf - the way it works, syntax etc, is easy to understand and use, but in the end it also just does what it's told to do ... and if that part is flawed, the result will be flawed as well. I have yet to find an "insane" default setting in OpenBSD. It all makes perfect sense, and it's wonderfully simple to go into any direction from these defaults. I see no reason in changing them into what's more suitable for special cases. The things you mention are/can be pretty large projects. Paranoia never really helps security -- all it can do is prevent people from thinking straight... or worse, make them alter paranoid default settings into utterly insecure ones just to get things working again - depending on whose paranoia needs to be dealt with. In my opinion, the OpenBSD folks are walking a fine line here and doing a good job at that. IMNSHO. And you cannot hide anything from the administrator. You depend on how well the admin is capable of securing the rest of the system and not have it rooted by a 3rd party(*) including the other users. Then you shouldn't use the system at all. It is not because something might be/become a flaw, that you don't have to care about the rest. Every extra layer of defence _does_ protect you from a subset of attacks, even how small that subset is, it counts. As for how far trust goes, this needs to be figured out on a case-by-case basis. You trust because something is made trustworthy - for example through transparency in what way security is enforced. But this digresses from talking about default settings, and in this regard there might've been a misunderstanding. I did not mean to not care about the rest, but you cannot expect most or all of it from a default installation. I hope my explanation above is clearer. The fine line is to have things secure but not paranoid (and thus dysfunctional for the majority of users.) I disagree with the proposed changes to /etc/skel, because I believe that what we have here is perfectly suited for most people, and easy enough to work with for those who have special needs. shell server. Who says that the admin is any more trustworthy than some other, regular users? They are not, but most of the time they give you confidential information that you must use on that box that you use for stuff other users may not access, like database/pop3 information. Huh, why would I give shell access (or even a system account) to anyone but fellow admins on a database or mail server in the first place? From a user perspective, I for one would rather Post-It[tm] complicated and unmemorizeable credentials to my monitor(*) where I have at least some idea about who might get to see them instead of putting them into my home directory on my own server at home, let alone some server someplace else. Moritz *: Just like some well-known security guy, whose name I forgot, suggested recently ... might've been a TheRegister article pointing to it.
Re: suggested /etc/skel/ modifications
Dave Feustel wrote: And there are also still numerous ways of breaking OpenBSD inspite of sane defaults and exploit mitigation techniques in place. Is there any way I can tell whether my system has been broken as you describe? This really depends ... I can't tell specifics. I mentioned this because of this anecdote: A pal once had to deal with a probably-owned OpenBSD box, because his clueless co-admin installed an outdated, vulnerable MySQL server by hand (not related to ports/packages at all), and likely configured it in a bad way, too. Some script kiddie managed to exploit whatever was going on there. He found out quickly because of an /etc/shadow file and maybe some other signs, IIRC ... I suspect that the cluelessness/idiocy of the s'kiddie, or simply the nature of the attack, resulted in no further damage, however, he reinstalled the box anyways and bitchslapped the co-admin. I'd like to be more specific, but there wasn't done any forensic analysis of the attack, and it's been a while, too. I think it was an OBSD 3.4 installation. My point is mostly that, if you try really hard, you can make an OpenBSD box insecure. OpenBSD can also not help you when you run an OpenBSD-aware trojan as root, for example. Moritz
Re: suggested /etc/skel/ modifications
Jonathan Schleifer wrote: This kind of paranoia adds nothing to security (~/.ssh and others that need it are already set to restrictive permissions), and there is no privacy from root no matter what. The rest is, again, personal preference and/or something about local policies. Ever heart of a multiuser system where one user shouldn't be able to acces the files of another user? Not all users are thinking about this issue and many forget to change the modes for confidential files. IMO, But keeping confidential files on "true" multiuser systems is stupid ... IMNSHO. And you cannot hide anything from the administrator. You depend on how well the admin is capable of securing the rest of the system and not have it rooted by a 3rd party(*) including the other users. Other than that, I wrote how easy it is to close down the home directories - the permissions of everything in /etc/skel, the directory itself included, propagate to new user's homedirectories. After that, things like the umask don't matter at all, because only the user him/herself and root can enter the respective homes. If I, as the admin, want or have to hide things from the users, then that's fine and not related to home directory permissions. Stuff like /etc/ssl/private. Other than that, I create new users for them to be able to work together, or with my own regular user account. Or, I create new users and give them certain administrative rights on a special purpose box. If I create new users for the sake of them having a Unix shell, then it's something different, but this is so very rare ... and there really shouldn't be any confidential things on such a multiuser shell server. Who says that the admin is any more trustworthy than some other, regular users? Moritz *: OpenBSD had only one remote hole in the default install, but a few more (very few, relatively speaking) local root vulnerabilities. And there are also still numerous ways of breaking OpenBSD inspite of sane defaults and exploit mitigation techniques in place. In the end, it simply boils down on properly assessing risks, giving a box a defined purpose (even if it's an "eierlegende Wollmilchsau"(**)), and enforcing an appropriate security and usage policy. Solving social problems with social means is often enough the only viable way. **: Rough translation: A fictional all-purpose animal; a sow that grows wool, gives milk and lays eggs.
Re: suggested /etc/skel/ modifications
Mh, I just deleted some text I wrote to 1) and 2), because most if it was already said. It boils down to "personal/administrational preference and/or policy", "the current defaults are just fine and logical" and "trivial to change". Dave Feustel wrote: Also modify adduser so that the home directory permissions of new users are set to drwx-- instead of drwxr-xr-x chmod 700 /etc/skel No real need for changing any scripts, and besides, home directories with a default mode of 700 would *really* annoy me. "Grab foo.txt fom my home direc... oh, wait, sorry - I have to log in and throw it in /tmp or something." This kind of paranoia adds nothing to security (~/.ssh and others that need it are already set to restrictive permissions), and there is no privacy from root no matter what. The rest is, again, personal preference and/or something about local policies. Moritz
Re: '.' in username
Thanos Tsouanas wrote: I just found out that chsh complains if a username has a '.' in it: % sudo chsh foo.bar [ ... ] chsh: '.' is dangerous in a login name I'm sure there's a reason (why? regexps involved?) but I think that since chsh complains, adduser should complain too. No? The reasons for usernames with periods in them being dangerous is related to chown(8) (and maybe other things): # mkdir test # cd test # useradd foo.bar useradd: Warning: home directory `/home/foo.bar' doesn't exist, and -m was not specified # useradd foo useradd: Warning: home directory `/home/foo' doesn't exist, and -m was not specified # groupadd bar # touch a # touch b # ls -l total 0 -rw-r--r-- 1 root wheel 0 Jul 20 13:32 a -rw-r--r-- 1 root wheel 0 Jul 20 13:32 b # chown foo.bar a # ls -l a -rw-r--r-- 1 foo.bar wheel 0 Jul 20 13:32 a # userdel foo.bar # chown foo.bar b # ls -l b -rw-r--r-- 1 foo bar 0 Jul 20 13:32 b # Even though the chown(8) man page states that the colon needs to be the separator between user and group, the period (still(?), maybe for historical/POSIXish reasons?) can function as the separator as well. This means that under certain (pretty rare) conditions, e.g. if the administrator forgot that foo.bar has been removed earlier (wrt the example above), chown does something that wasn't intended instead of printing the error that user "foo.bar" does not exist. Assumed that this is the only place where '.' is dangerous in usernames, the proper solution would probably be to compile chown in /usr/src/bin/chmod with SUPPORT_DOT as undefined and to remove the is-dangerous warning from all other places, like chsh ... and be prepared to redirect lots of confused users to the manpage. Alternatively, you could make it a policy to not user periods in usernames on your system(s) or live with the effect that they can have and simply be aware of them. Whether making useradd and adduser complain is a good idea or not, I do not know. Maybe it's even okay to just remove the warning from chsh in any case, since it doesn't appear to be the appropriate tool to issue such a warning. Moritz
Re: Release/version/patch management question
Hi, as an addendum to Jason Crawford's answer to your mail, also note that there is a nice release(8) man page. Since going from -release to -stable doesn't involve any of the manual steps like upgrading from release to release or release/-stable to -current, things are really straightforward - no surprises and only very little to do wrong. The way things are on OpenBSD, it is just as manageable as any other OS, except it's a bit different and some infrastructure makes it simple and fast - like a build box. Markus Wernig wrote: [getting rid of unneeded services, completely] low on disk space). It's probably more a question of mindset. Up to now I was used to controlling which software went on my system and which didn't. You are not relinquishing this control on OpenBSD either; there are knobs that make it relatively easy to make highly customized releases.(*) However, since OpenBSD needs to be taken as a whole -- kernel, userland, ports tree and X11 -- pushing these knobs will leave you with something that isn't OpenBSD anymore. One of the core points of the *BSDs is to have an operating system, whose components work together without being completely independent. Sometimes, in very rare and/or special cases, it may be worth giving up running "supported OpenBSD". However, a certain mindset whose only result is not wanting to spend 2MB (give or take) of diskspace for a perfectly integrated httpd and named that aren't running nor doing anything bad anyways is most likely not a good reason and not worth the trouble. So ... you'll get over it. ;-) Moritz *: That is, when it's about taking things away from or changing things inside the OS. To add stuff, you don't need to go through that trouble - instead, read up on ``siteXY.tgz''.
Re: Why timezone it is always incorrect??
C. L. Martinez wrote: Is not possible to adjust clock under OpenBSD correctly??? I do not understand why cmos clock needs to leave at UTC. why? Do i need to recompile kernel with TIMEZONE option to correct this "bug"?? Is not possible to use sysctl tool to correct this??? Aside from me considering Windows' inability to leave the clock at UTC where it belongs, I solved this by simply using NTP in both OSes on my dual-boot box. That way I don't have to muck about with config(8) or even kernel configurations. A nice side-effect is that my clock's always set to the exact time. OpenNTPd makes this trivial on OpenBSD (in combination with rdate on 3.6), and Windows can listen to time servers, too. Moritz
