strange behaviour with pkg_add -z
Hi, i need to script some packages install, so i tried to use pkg_add -z option like this: pkg_add -vzI python-idle-2 python-idle-2.7.5p0: ok --- +python-idle-2.7.5p0 --- If you want to use this package as your default system idle, as root create symbolic links like so (overwriting any previous default): ln -sf /usr/local/bin/idle2.7 /usr/local/bin/idle Packages with signatures: 1 So it seems to work, but when i give another try with: pkg_add -vzI python-idle-3 Ambiguous: python-idle-3 could be python-idle-2.7.5p0 python-idle-3.3.2p0 So i don't really understand why i doesn't work with '-3'... After deleting 'python-idle', i tried again to install python-idle-3 first and... same problem. I tried with 'python' package too without success. So it seems that only a command like 'pkg_add -vzI mypackage-2' will work. Is it a bug or simply something i didn't understand ? Thanks Morgan
Re: strange behaviour with pkg_add -z
On Thu, Mar 06, 2014 at 09:59:07AM +0100, Comète wrote: > Hi, > > i need to script some packages install, so i tried to use pkg_add -z > option like this: > > pkg_add -vzI python-idle-2 > > python-idle-2.7.5p0: ok > --- +python-idle-2.7.5p0 --- > If you want to use this package as your default system idle, as root > create symbolic links like so (overwriting any previous default): > ln -sf /usr/local/bin/idle2.7 /usr/local/bin/idle > Packages with signatures: 1 > > So it seems to work, but when i give another try with: > > pkg_add -vzI python-idle-3 > Ambiguous: python-idle-3 could be python-idle-2.7.5p0 > python-idle-3.3.2p0 > > So i don't really understand why i doesn't work with '-3'... > After deleting 'python-idle', i tried again to install python-idle-3 > first and... same problem. > > I tried with 'python' package too without success. > > So it seems that only a command like 'pkg_add -vzI mypackage-2' will > work. > > Is it a bug or simply something i didn't understand ? It's a limitation, not a bug. 3 doesn't look like anything in particular to pkg_add. It's more likely to converge with a real version number, like pkg_add -z python-idle-3.3.0 ought to work better.
Re: [patch] vmstat(8) usage
On Mon, Mar 03, 2014 at 04:03:08PM +, Jason McIntyre wrote: > On Sat, Mar 01, 2014 at 09:34:10PM +0100, Denis Fondras wrote: > > Hi all, > > > > I've just discovered that OpenBSD vmstat(8) can use wait and count > > arguments without using -c/-w. Here is a small patch to mention this > > usage in the manual : > > > > Regards, > > Denis > > > > --- vmstat.8.orig Sun Feb 23 15:50:17 2014 > > +++ vmstat.8Sun Feb 23 15:54:24 2014 > > @@ -45,6 +45,11 @@ > > .Op Fl N Ar system > > .Op Fl w Ar wait > > .Op Ar disk ... > > +.Nm vmstat > > +.Op Ar wait Op Ar count > > +.Op Fl M Ar core > > +.Op Fl N Ar system > > +.Op Ar disk ... > > .Sh DESCRIPTION > > .Nm > > reports certain kernel statistics kept about process, virtual memory, > > > > hi. i don;t much like adding another synopsis for this. it's just makes > it more complicated, without adding much. > > i note usage() and SYNOPSIS are already out of sync here ;( i had no > idea we had split synopsis up this way. > > i guess, properly, we should somehow show stuff like: [[-c] count] > or just reword the description of the options to say under which > circumstances it's optional. > > and looking at BUGS: > > This manual page lacks an incredible amount of detail. > > we could just paste this into all our pages ;) > > before doing anything, i'd like to ask if anyone knows of a reason why > we wouldn;t document this, or the history of when this was added? > > i'll think on it a bit more. > > jmc no one has replied, so i'll just say i don;t want to do this. i already dislike that we've split SYNOPSIS into two forms (where neither freebsd or netbsd have), and i don;t see a third form adding much. and i don;t see a way to add this to SYNOPSIS correctly without adding a third form ;) i think trying to document it is just going to make for more confusing text. think of it as a trick that only you know! sorry, jmc
Linux partition appears as ext2 partition in disklabel
Hello! I have a strange problem. Recently I added following to my /etc/fstab: /dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0 I can't mount this partition using "mount -a": $ sudo mount -a mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs The same message appears on boot. Still, I can mount it by hand: $ sudo mount /mnt/arch $ mount /dev/sd0a on / type ffs (local) /dev/sd0d on /home type ffs (local, nodev, nosuid) /dev/sd0i on /mnt/arch type ext2fs (local, nodev, noexec, nosuid) The partition is actually of type 0x83, and the first 2 Mb of disk were zero-outed before Linux and OpenBSD were installed. If it is of any importance, the system is Lenovo ThinkPad E325, and the Linux partition contains working, bootable Archlinux installation. Bootloader is Syslinux. I'm running OpenBSD-current from snapshots, updating every several days. First time I tried it was probably about a week ago and it consistently keeps behaving the same. == Fdisk == Disk: sd0 geometry: 38913/255/63 [625142448 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- *0: 83 0 32 33 - 6527 53 54 [2048: 104857600 ] Linux files* 1: A6 6527 53 55 - 38912 254 63 [ 104859648: 520277697 ] OpenBSD 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused == Disklabel == # /dev/rsd0c: type: SCSI disk: SCSI disk label: ST320LT007-9ZV14 duid: d02babcb5f5d80c4 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 38913 total sectors: 625142448 boundstart: 104859648 boundend: 625137345 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 33556384104859648 4.2BSD 2048 163841 # / b: 8385938138416032swap # none c:6251424480 unused d:478335360146801984 4.2BSD 4096 327681 # /home i:104857600 2048NTFS # /mnt/arch == Dmesg == OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3849388032 (3671MB) avail mem = 3738304512 (3565MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf9d00 (58 entries) bios0: vendor LENOVO version "8SET33WW (1.15 )" date 11/17/2011 bios0: LENOVO 12972UG acpi0 at bios0: rev 4 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC HPET APIC MCFG UEFI UEFI SSDT SSDT UEFI acpi0: wakeup devices PB4_(S4) PB5_(S4) PB6_(S4) PB7_(S4) OHC1(S3) EHC1(S3) OHC2(S3) SBAZ(S4) GEC_(S4) P2P_(S5) SPB0(S4) SPB1(S4) SPB2(S4) SPB3(S4) LID_(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD E-450 APU with Radeon(tm) HD Graphics, 1647.48 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD E-450 APU with Radeon(tm) HD Graphics, 1646.49 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2
Re: Linux partition appears as ext2 partition in disklabel
On Thu, Mar 06, 2014 at 18:49, Dmitrij D. Czarkoff wrote: > Hello! > > I have a strange problem. Recently I added following to my /etc/fstab: > > /dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0 > > I can't mount this partition using "mount -a": > > $ sudo mount -a > mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs > i:104857600 2048NTFS # /mnt/arch Edit the disklabel to say ext2fs?
Re: [patch] vmstat(8) usage
On Sat, Mar 01, 2014 at 21:34, Denis Fondras wrote: > Hi all, > > I've just discovered that OpenBSD vmstat(8) can use wait and count > arguments without using -c/-w. Here is a small patch to mention this > usage in the manual : This is a holdover from olden days. If I could kill it, I would, so maybe best not to rely on it.
Re: [patch] vmstat(8) usage
> On Sat, Mar 01, 2014 at 21:34, Denis Fondras wrote: > > Hi all, > > > > I've just discovered that OpenBSD vmstat(8) can use wait and count > > arguments without using -c/-w. Here is a small patch to mention this > > usage in the manual : > > This is a holdover from olden days. If I could kill it, I would, so > maybe best not to rely on it. That's right. Back in the grand old days when the CSRG guys would regularily join in the drum circle at the edge of UCB campus, argv handling was still very different from program to program, and getopt() was still young. If you dig around, you'll find quite a few commands with hidden arguments like this, and most have Berkeley origins. The most common ones are so familiar that they cannot be removed, there are even a few cases of POSIX bending over backwards to admit they exist. A good example is ps(1). You don't need the '-'.
Re: Linux partition appears as ext2 partition in disklabel
On 6 March 2014 12:49, Dmitrij D. Czarkoff wrote: > Hello! > > I have a strange problem. Recently I added following to my /etc/fstab: > > /dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0 > > I can't mount this partition using "mount -a": > > $ sudo mount -a > mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs > > The same message appears on boot. Still, I can mount it by hand: > > $ sudo mount /mnt/arch > $ mount > /dev/sd0a on / type ffs (local) > /dev/sd0d on /home type ffs (local, nodev, nosuid) > /dev/sd0i on /mnt/arch type ext2fs (local, nodev, noexec, nosuid) > > The partition is actually of type 0x83, and the first 2 Mb of disk were > zero-outed before Linux and OpenBSD were installed. If it is of any > importance, the system is Lenovo ThinkPad E325, and the Linux partition > contains working, bootable Archlinux installation. Bootloader is > Syslinux. > > I'm running OpenBSD-current from snapshots, updating every several days. > First time I tried it was probably about a week ago and it consistently > keeps behaving the same. > > > == > Fdisk > == > > Disk: sd0 geometry: 38913/255/63 [625142448 Sectors] > Offset: 0 Signature: 0xAA55 > Starting Ending LBA Info: > #: id C H S - C H S [ start:size ] > --- > *0: 83 0 32 33 - 6527 53 54 [2048: 104857600 ] Linux > files* > 1: A6 6527 53 55 - 38912 254 63 [ 104859648: 520277697 ] OpenBSD > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > > > == > Disklabel > == > > # /dev/rsd0c: > type: SCSI > disk: SCSI disk > label: ST320LT007-9ZV14 > duid: d02babcb5f5d80c4 > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 38913 > total sectors: 625142448 > boundstart: 104859648 > boundend: 625137345 > drivedata: 0 > > 16 partitions: > #size offset fstype [fsize bsize cpg] > a: 33556384104859648 4.2BSD 2048 163841 # / > b: 8385938138416032swap # none > c:6251424480 unused > d:478335360146801984 4.2BSD 4096 327681 # /home > i:104857600 2048NTFS # /mnt/arch Your disklabel seems to have NTFS down as the file system for 'i'. Which might explain the error and inconsistant behaviour. This may be an old disklabel, since zero'ing out the first 2MB doesn't look like it would have reached the OpenBSD partition where the disklabel would be stored. I created an MBR with partition 0 of type 0x83, and disklabel here spoofs that correctly to 'ext2fs'. What does 'disklabel -d sd0' show? Ken
Re: Linux partition appears as ext2 partition in disklabel
Ted Unangst said: > On Thu, Mar 06, 2014 at 18:49, Dmitrij D. Czarkoff wrote: > > Hello! > > > > I have a strange problem. Recently I added following to my /etc/fstab: > > > > /dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0 > > > > I can't mount this partition using "mount -a": > > > > $ sudo mount -a > > mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs > > > i:104857600 2048NTFS # /mnt/arch > > Edit the disklabel to say ext2fs? I was under impression that fdisk edits MBR partitions and disklabel only edits BSD labels. Anyway: $ sudo disklabel -E sd0 Label editor (enter '?' for help at any prompt) > p OpenBSD area: 104859648-625137345; size: 520277697; free: 15 #size offset fstype [fsize bsize cpg] a: 33556384104859648 4.2BSD 2048 163841 # / b: 8385938138416032swap # none c:6251424480 unused d:478335360146801984 4.2BSD 4096 327681 # /home i:104857600 2048NTFS # /mnt/arch > m i offset: [2048] The offset must be >= 104859648 and < 625137345, the limits of the OpenBSD portion of the disk. The 'b' command can change these limits. > Any other ideas? -- Dmitrij D. Czarkoff
Re: Linux partition appears as ext2 partition in disklabel
On 6 March 2014 13:23, Dmitrij D. Czarkoff wrote: > Ted Unangst said: >> On Thu, Mar 06, 2014 at 18:49, Dmitrij D. Czarkoff wrote: >> > Hello! >> > >> > I have a strange problem. Recently I added following to my /etc/fstab: >> > >> > /dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0 >> > >> > I can't mount this partition using "mount -a": >> > >> > $ sudo mount -a >> > mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs >> >> > i:104857600 2048NTFS # >> > /mnt/arch >> >> Edit the disklabel to say ext2fs? > > I was under impression that fdisk edits MBR partitions and disklabel > only edits BSD labels. Anyway: > > $ sudo disklabel -E sd0 > Label editor (enter '?' for help at any prompt) > > p > OpenBSD area: 104859648-625137345; size: 520277697; free: 15 > #size offset fstype [fsize bsize cpg] > a: 33556384104859648 4.2BSD 2048 16384 1 # / > b: 8385938138416032swap # none > c:6251424480 unused > d:478335360146801984 4.2BSD 4096 327681 # /home > i:104857600 2048NTFS # > /mnt/arch > > m i > offset: [2048] > The offset must be >= 104859648 and < 625137345, the limits of the > OpenBSD portion > of the disk. The 'b' command can change these limits. > > > > Any other ideas? delete the partition 'i'. You don't need it, as it will be automatically created when necessary. Ken > > -- > Dmitrij D. Czarkoff
Re: Linux partition appears as ext2 partition in disklabel
Kenneth Westerback said: > delete the partition 'i'. You don't need it, as it will be > automatically created when necessary. Thanks! Apparently it wasn't re-created automatically, but I could rebuild my disklabel using "disklabel -dE sd0", so now it works as expected. -- Dmitrij D. Czarkoff
Re: IPSec Packet Loss Help
On Wed, Mar 05, 2014 at 11:05:11PM -0600, Amit Kulkarni wrote: > > If PF information is needed, I can provide and obscure, but I didn't > > expect it to be > > the issue. > > > > i am no expert on this. but if it is a packet loss issue, you need to post > the obscured pf.conf Fair point. I've not seen any related dropped packets due to PF with tcpdump -nei pflog0, so I didn't think it would be related to PF. Not line-wrapped for readability. match out on em0 from ! (em0:network) to any nat-to (em0:0) block drop in log all pass out all flags S/SA pass out on em0 proto tcp all flags S/SA modulate state pass in proto icmp from to pass in proto ipv6-icmp from to pass in from to ! flags S/SA pass in from to any flags S/SA pass in proto udp from to port = 53 pass out on em0 proto udp all pass out on em0 proto icmp all pass on em0 inet proto carp all pass on em0 proto icmp from any to (em0:network) pass on em1 inet proto pfsync all pass in on em0 inet proto udp from 66.77.88.10 to 1.2.3.5 port = 500 pass in on em0 inet proto udp from 66.77.88.10 to 1.2.3.5 port = 4500 pass in on em0 inet proto esp from 66.77.88.10 to 1.2.3.5 pass in on enc0 inet proto ipencap from 66.77.88.10 to 1.2.3.5 keep state (if-bound) pass out on em0 inet proto udp from 1.2.3.5 to 66.77.88.10 port = 500 pass out on em0 inet proto udp from 1.2.3.5 to 66.77.88.10 port = 4500 pass out on em0 inet proto esp from 1.2.3.5 to 66.77.88.10 pass out on enc0 inet proto ipencap from 1.2.3.5 to 66.77.88.10 keep state (if-bound) pass out on enc0 inet from 1.2.3.5 to flags S/SA keep state (if-bound) pass out on enc0 from to flags S/SA keep state (if-bound) pass in on enc0 from to flags S/SA keep state (if-bound) pass in on enc0 inet from 66.77.88.10 to flags S/SA keep state (if-bound) pass in on em0 inet proto tcp from 66.77.88.17 to any port = 22 flags S/SA pass in on em0 inet proto tcp from 1.2.3.7 to 1.2.3.6 port = 500 flags S/SA This morning as a test, I've disabled isakmpd sync feature, and shutdown sasycnd on all firewalls, as well as isakmpd on the secondaries at each location and the connection seems to be much improved. I've not lost any connections in the last 4 hours which is much improved. Not sure if sasyncd is actually causing the issue, but disabling it to gain an improved connections certainly doesn't seem great from an HA standpoint. I've also got a couple static routes in the inet table that point the remote network to the internal carp address for routing purposes. This allows the traffic generated by the secondary firewall to reach the remote network due to the fact that the secondary does not hold the master status of the carp, and therfore can't use the IPSec directly. I do wonder though, since I also have a flow for the same network, the encap and inet routing table have a route for the same network. Which takes priority? Just something to point out since it could be causing troubles. Regards, -- Zach
Re: Linux partition appears as ext2 partition in disklabel
On March 6, 2014 7:23:50 PM CET, "Dmitrij D. Czarkoff" wrote: >Ted Unangst said: >> On Thu, Mar 06, 2014 at 18:49, Dmitrij D. Czarkoff wrote: >> > Hello! >> > >> > I have a strange problem. Recently I added following to my >/etc/fstab: >> > >> > /dev/sd0i /mnt/arch ext2fs rw,nodev,nosuid,noexec 0 0 >> > >> > I can't mount this partition using "mount -a": >> > >> > $ sudo mount -a >> > mount: /dev/sd0i: fstab type ext2fs != disklabel type ntfs >> >> > i:104857600 2048NTFS # >/mnt/arch >> >> Edit the disklabel to say ext2fs? > >I was under impression that fdisk edits MBR partitions and disklabel >only edits BSD labels. Anyway: > > $ sudo disklabel -E sd0 > Label editor (enter '?' for help at any prompt) > > p > OpenBSD area: 104859648-625137345; size: 520277697; free: 15 > #size offset fstype [fsize bsize cpg] >a: 33556384104859648 4.2BSD 2048 163841 # / > b: 8385938138416032swap # none >c:6251424480 unused > d:478335360146801984 4.2BSD 4096 327681 # /home >i:104857600 2048NTFS # > /mnt/arch > > m i > offset: [2048] > The offset must be >= 104859648 and < 625137345, the limits of the > OpenBSD portion > of the disk. The 'b' command can change these limits. > > > >Any other ideas? Read the error message you just posted? /Alexander
Re: IPSec Packet Loss Help
Hi, haven't read your original email but if my assumptions about your setup are correct is the VPN tunnel dropping every now and then? I had a similar issue with 4 OBSD firewalls (2 at each end), all running isakmpd and sasyncd to keep the SAs in sync between a pair. With the tunnels explicitly set to use the CARP IPs as endpoints. You need the static route to point to the internal interface to make sure that packets generated by the firewall itself have a source IP set to the internal net thus allowing the IPSec policy route to be used (as it defines both the source and dest net, not just the dest net like a normal route). However whilst pinging the remote net from the live firewall works, I found that if you try and ping the remote net from the backup firewall, the packet does *not* get routed to the CARP master (why would it!). The IPSec route is there.. The backup firewall encaps the packet and sends it out its own external interface using the dets from sasyncd, but the master firewall at the other end will see the packet as coming from 'another' box with the same details but not the full correct policy and so the tunnel is blocked for a period until the master renegotiates it. We had to modify all our monitoring scripts to not 'phone home' if the box is a backup. Only the master firewall can use the VPN. I also submitted some suggested modifications to /etc/rc.d/sasyncd and /etc/rc.d/isakmpd here in the past which makes the setup and failover of VPNs much faster and more stable. Can dig out if you can't find them. Cheers, Andy Sent from my iPhone > On 6 Mar 2014, at 19:00, Zach Leslie wrote: > > On Wed, Mar 05, 2014 at 11:05:11PM -0600, Amit Kulkarni wrote: >>> If PF information is needed, I can provide and obscure, but I didn't >>> expect it to be >>> the issue. >> >> i am no expert on this. but if it is a packet loss issue, you need to post >> the obscured pf.conf > > Fair point. I've not seen any related dropped packets due to PF with > tcpdump -nei pflog0, so I didn't think it would be related to PF. > > Not line-wrapped for readability. > > match out on em0 from ! (em0:network) to any nat-to (em0:0) > block drop in log all > pass out all flags S/SA > pass out on em0 proto tcp all flags S/SA modulate state > pass in proto icmp from to > pass in proto ipv6-icmp from to > pass in from to ! flags S/SA > pass in from to any flags S/SA > pass in proto udp from to port = 53 > pass out on em0 proto udp all > pass out on em0 proto icmp all > pass on em0 inet proto carp all > pass on em0 proto icmp from any to (em0:network) > pass on em1 inet proto pfsync all > pass in on em0 inet proto udp from 66.77.88.10 to 1.2.3.5 port = 500 > pass in on em0 inet proto udp from 66.77.88.10 to 1.2.3.5 port = 4500 > pass in on em0 inet proto esp from 66.77.88.10 to 1.2.3.5 > pass in on enc0 inet proto ipencap from 66.77.88.10 to 1.2.3.5 keep state > (if-bound) > pass out on em0 inet proto udp from 1.2.3.5 to 66.77.88.10 port = 500 > pass out on em0 inet proto udp from 1.2.3.5 to 66.77.88.10 port = 4500 > pass out on em0 inet proto esp from 1.2.3.5 to 66.77.88.10 > pass out on enc0 inet proto ipencap from 1.2.3.5 to 66.77.88.10 keep state > (if-bound) > pass out on enc0 inet from 1.2.3.5 to flags S/SA keep state > (if-bound) > pass out on enc0 from to flags S/SA keep state > (if-bound) > pass in on enc0 from to flags S/SA keep state > (if-bound) > pass in on enc0 inet from 66.77.88.10 to flags S/SA keep state > (if-bound) > pass in on em0 inet proto tcp from 66.77.88.17 to any port = 22 flags S/SA > pass in on em0 inet proto tcp from 1.2.3.7 to 1.2.3.6 port = 500 flags S/SA > > This morning as a test, I've disabled isakmpd sync feature, and shutdown > sasycnd on all firewalls, as well as isakmpd on the secondaries at each > location and the connection seems to be much improved. I've not lost > any connections in the last 4 hours which is much improved. > > Not sure if sasyncd is actually causing the issue, but disabling it > to gain an improved connections certainly doesn't seem great from an HA > standpoint. > > I've also got a couple static routes in the inet table that point the > remote network to the internal carp address for routing purposes. This > allows the traffic generated by the secondary firewall to reach the > remote network due to the fact that the secondary does not hold the > master status of the carp, and therfore can't use the IPSec directly. > > I do wonder though, since I also have a flow for the same network, the > encap and inet routing table have a route for the same network. Which > takes priority? Just something to point out since it could be causing > troubles. > > Regards, > > -- > Zach
Re: Linux partition appears as ext2 partition in disklabel
On 6 March 2014 13:59, Dmitrij D. Czarkoff wrote: > Kenneth Westerback said: >> delete the partition 'i'. You don't need it, as it will be >> automatically created when necessary. Something would have been added. Again, the output of 'disklabel -d sd0' would be useful. Ken > > Thanks! > > Apparently it wasn't re-created automatically, but I could rebuild my > disklabel using "disklabel -dE sd0", so now it works as expected. > > -- > Dmitrij D. Czarkoff
Re: prices of cdset in eu
On 3/03/2014 22:59, Peter N. M. Hansteen wrote: Axel Scheepers writes: Can anyone tell me about the difference in price regarding a cdset in EU? original ca $50 36.41 (CA) mensys eur 50,- vat incl. 60.50 (NL) comcol.nl same as mensys, 60,50 (NL) getdigital(de)39,00 (DE) lehmanns media39,95 (DE) My guess is that the differences between the EU outlets comes in apart at least from the size of batches they order -- larger orders get discounts. I've tended to order from the CA one unless early copies have turned up at a conference I've been to and I hadn't gotten around to order yet. And I suppose there is a better range T-shirts and other related mercandise if you order from there. I've had a few of the packages from Canada stopped for extra customs inspection (with an aditional fee, of course), but it's been a while since that happened. That in turn could mean the Norwegian customs organization are actually learning to spend their resources wisely. - Peter Looks like those customs guys moved to Belgium... :( I never had issues with customs before until now. Now they want to charge me 86€ on taxes on a shipment of 240€! Though luck guys, I'm not paying that. I rather send 86€ to the project so I'm sure the money is used for something useful. PS: For those ordering stuff in the Computer Shop from Belgium: keep the total cost below 150€. Below 150€ they "only" charge you 12€ for "administrative costs" + 21% VAT on the whole package price (or they don't charge you at whole like I had with all my previous shipments). For shipments above 150€ (first time for me) they charge you 30€ +21% VAT. HTH, Stijn
Re: prices of cdset in eu
Hi, as you are in Europe, you might also consider this online shop: http://openbsdeurope.com/ It's not associated with the project, but so far worked reliably for me. Shipping to Germany, they charged me 39.75 Pound Sterling including Taxes and shipping for one 5.4 CD, which ended up as 46.76 Euro grand total on my credit card including bank fees. That seemed more or less reasonable to me. It doubt it will be much different in Belgium, given that Germany and Belgium are both in the EU. Of course, an additional donation using the usual channels is always welcome. :-) Yours, Ingo
Re: Linux partition appears as ext2 partition in disklabel
[cc:ing misc@ for the archives] On 03/06/14 21:29, Dmitrij D. Czarkoff wrote: Alexander Hall said: The offset must be >= 104859648 and < 625137345, the limits of the OpenBSD portion of the disk. The 'b' command can change these limits. > Any other ideas? Read the error message you just posted? I thought that bounds of BSD label should correspond to MBR partition holding such label. Am I wrong? At least disklabel(8) warns against extending them beyond this limit. Normally, yes, and those bounds are what you are experiencing. However, to be able to reach disk areas lying outside the A6 partition (in this case, the ext2fs partition) from within OpenBSD, it needs to be mapped to a partition in the disklabel. Therefore you need to circumvent those bounds using the suggested 'b' command. Unless you, as noted, started over with a default disklabel, which will automatically set up disklabel partitions for some (but not all IIRC) "external" fdisk entries, starting from i: and up. /Alexander
Re: Linux partition appears as ext2 partition in disklabel
On Thu, Mar 06, 2014 at 23:06, Alexander Hall wrote: >> I thought that bounds of BSD label should correspond to MBR partition >> holding such label. Am I wrong? At least disklabel(8) warns against >> extending them beyond this limit. Of course. If you start using some other operating system's space for OpenBSD, you're going to write over that other system's data. In this case, that's exactly what you want.
Re: IPSec Packet Loss Help
On Thu, Mar 06, 2014 at 08:16:34PM +, Andy Lemin wrote: > Hi, haven't read your original email but if my assumptions about your setup > are correct is the VPN tunnel dropping every now and then? Thats correct. Daemons start up quick, negotiations happen, and then periodically the tunnel is just not available, despite the SAs being available on the masters and the slaves. Disabling -S on isakmpd and turning off sasyncd makes the tunnel stay up for much longer, 7 hours and counting. > You need the static route to point to the internal interface to make sure > that packets generated by the firewall itself have a source IP set to the > internal net thus allowing the IPSec policy route to be used (as it defines > both the source and dest net, not just the dest net like a normal route). This I have, and packets flow. Still unclear about which route takes precedence, encap or inet. > We had to modify all our monitoring scripts to not 'phone home' if the box is > a backup. Only the master firewall can use the VPN. I've ended up monitoring the host using internal interface, which in turn tells me the tunnel is available. > I also submitted some suggested modifications to /etc/rc.d/sasyncd and > /etc/rc.d/isakmpd here in the past which makes the setup and failover of VPNs > much faster and more stable. I did see those scripts, though they seem to be more solving the startup time of the daemons. My issue is more keeping the service up than start time. It sounds like your setup is similar to my own. You don't see theses kinds of instability using sasyncd? If you have a look at my OP, the sasyncd.conf is in there. Its possible I have a configuration error, but just reading over the manpage again, I don't know what it would be. This is really troubling me. -- Zach
Re: prices of cdset in eu
On 6/03/2014 22:52, Ingo Schwarze wrote: Hi, as you are in Europe, you might also consider this online shop: http://openbsdeurope.com/ It's not associated with the project, but so far worked reliably for me. Shipping to Germany, they charged me 39.75 Pound Sterling including Taxes and shipping for one 5.4 CD, which ended up as 46.76 Euro grand total on my credit card including bank fees. That seemed more or less reasonable to me. It doubt it will be much different in Belgium, given that Germany and Belgium are both in the EU. Of course, an additional donation using the usual channels is always welcome. :-) Yours, Ingo Yeah, I know about them, but they didn't had the 2.x CD's I was still lacking... G, Stijn
Re: ypldap 1024 character limit on groups?
On Mar 3, 2014, at 3:14 PM, Israel Brewster wrote: > I am working on setting up my OpenBSD 5.2 box to connect to my company LDAP > server (Mac OS X 10.8.5 OpenDirectory). I have successfully installed > login_ldap from ports and configured ypldap and the login.conf file such that > I can now authenticate as any of my ldap users. However, when ypldap pulls in > the group membership information from my LDAP server, it appears to be cutting > off the group membership listing at 1024 characters. The end result is that > only about half of my users are actually showing up as members of the > appropriate group(s). I have confirmed this not only by behavior (sftp is not > chrooted for some users even though I have the proper entries to match the > group in sshd_conf), but also by using the userinfo command: userinfo for a > user that shows up in the first 1024 characters of the group membership > listing properly shows the user as a member of the group. userinfo for a user > that does not show up in the first 1024 characters show the user as only being > part of the default group (staff in this case). How can I get ypldap to show > the full member listing? > --- > Israel Brewster > Computer Support Technician II > Era Alaska > 5245 Airport Industrial Rd > Fairbanks, AK 99709 > (907) 450-7250 x7293 > --- > I was thinking: is there any chance this is due to a problem with the Apple OpenDirectory LDAP, and not with ypldap? When I use a LDAB browser such as explorer, it shows all the groups, but perhaps it works differently. Any suggestions would be appreciated, as right now the LDAP binding is useless, and if I can't get this working I'll have to start over on a different OS where I can make this work - which will not be fun :-(. Thanks. --- Israel Brewster Computer Support Technician II Era Alaska 5245 Airport Industrial Rd Fairbanks, AK 99709 (907) 450-7250 x7293 --- [demime 1.01d removed an attachment of type text/directory which had a name of Israel Brewster.vcf]
Re: ypldap 1024 character limit on groups?
On Mon, Mar 3, 2014 at 4:14 PM, Israel Brewster wrote: > I am working on setting up my OpenBSD 5.2 box to connect to my company LDAP > server (Mac OS X 10.8.5 OpenDirectory). I have successfully installed > login_ldap from ports and configured ypldap and the login.conf file such that > I can now authenticate as any of my ldap users. However, when ypldap pulls in > the group membership information from my LDAP server, it appears to be cutting > off the group membership listing at 1024 characters. The end result is that > only about half of my users are actually showing up as members of the > appropriate group(s). I have confirmed this not only by behavior (sftp is not > chrooted for some users even though I have the proper entries to match the > group in sshd_conf), but also by using the userinfo command: userinfo for a > user that shows up in the first 1024 characters of the group membership > listing properly shows the user as a member of the group. userinfo for a user > that does not show up in the first 1024 characters show the user as only being > part of the default group (staff in this case). How can I get ypldap to show > the full member listing? The 1024 byte limit is hardcoded in libc's getgr* routines. /usr/src/lib/libc/gen/getgrent.c:#defineMAXLINELENGTH 1024 /usr/src/lib/libc/gen/getgrouplist.c:#define MAXLINELENGTH 1024 Increasing those would also require an increase to grp.h's _GR_BUF_LEN and possibly other places in the tree. Not tested: good luck! Philip Guenther
Re: NAT reliability in light of recent checksum changes
On 27/02/2014, at 11:04 AM, Theo de Raadt wrote: > > There was a method of converting an in-bound checksum, due to NAT > conversion, into a new out-bound checksum. A process is required, > it's how NAT works. > > A new method of version is being used. It is mathematically equivelant > to the old method. First, I agree with Theo that modifying a checksum is mathematically equivalent to regenerating it; both give the same result on ideal hardware. Of course, we use checksums because our hardware isn't ideal, so let's look at how the two approaches differ when a router fault occurs. Take Stuart Henderson's example: > Consider this scenario, which has happened in real life. > > - NIC supports checksum offloading, verified checksum is OK. > > - PCI transfers are broken (in my case it affected multiple > machines of a certain type, so most likely a motherboard bug), > causing some corruption in the payload, but the machine won't > detect them because it doesn't look at checksums itself, just > trusts the NIC's "rx csum good" flag. > > In this situation, packets which have been NATted that are > corrupt now get a new checksum that is valid; so the final > endpoint can not detect the breakage. That is, when the router offloads and regenerates, the router's egress NIC will hide any card, stack, bus or memory fault a verified packet suffered in passing through the router when it regenerates a new checksum from the now corrupt data. Looking at the code, the relevant functions are pf.c:pf_check_proto_cksum(), which trusts the ingress NIC's checksum good flag, and pf.c:pf_cksum(), which zeros the existing checksum on that basis and flags it to be regenerated by the egress NIC[1]. By contrast, checksum modification is far more reliable. In order to hide payload corruption the update code[1] would have to modify the checksum to exactly account for it. But that would have to happen by accident --- by a fault that in effect computes the necessary change --- as the update code never considers the payload[0]. It's not impossible but, on the other hand, checksum regeneration guarantees to hide faults in the regenerating router. We conclude that in the typical offloading case, regenerated checksums, unlike modified ones, cannot detect faults in the regenerating routers. Whether this difference is significant is a matter of judgment and a separate issue. I've some ideas about solutions but will leave those for another email. best, Richard. PS. I find the following terminology helpful: Checksums calculated from the origin data are 'original'; checksums calculated from a copy are 'regenerated'. Checksums may also be 'modified' to account for altered data in such a way as to preserve originality for any unaltered data[0]. A checksum is 'end-to-end' if it is delivered original with respect to the payload. A modified checksum may be end-to-end but never a regenerated checksum as it is not original. [0] Strikingly, RFC1631 (1994) and RFC3022 (2001), the NAT RFCs, fail to say end-to-end preservation is a property of their checksum modification algorithm. I presume it just didn't seem worth mentioning as, lacking hardware offload back then, one wouldn't regenerate in software on performance grounds alone. It is only alluded to in RFC1071 (1988) "Computing the Internet Checksum", which states that a checksum remains end-to-end when modified 'since it was not fully recomputed'. Although that's still true if NAT modifies it, NAT makes the meaning of 'end-to-end' more complex; I think my above terminology helps there. [1] I'll quote OpenBSD code here for completeness, contrasting modification (OpenBSD 5.3) with regeneration (OpenBSD 5.4) OpenBSD 5.3 NAT modified the checksum as follows: --- pf.c 1.818 (OPENBSD_5_3) --- Assuming an AF_INET <-> AF_INET TCP connection. pf_test_rule() 3862: pf_translate() 3881: pf_change_ap() [ src addr/port ] 1671: PF_ACPY [ = pf_addrcpy() ] 1689: pf_cksum_fixup(...) [ psuedo code is: sum = fixup(sum, addr16[1]) sum = fixup(sum, addr16[0]) sum = fixup(sum, port) ] 1662: l = cksum + old - new <--- checksum modified [ then presumably account for ones-complement carries ] 3887: pf_change_ap() etc [ dst addr/port ] On subsequent state matching: pf_test() 6788: pf_test_state_tcp() [ for TCP ] 4566: pf_change_ap() etc [ for src addr/port ] 4574: pf_change_ap() etc [ for dst addr/port ] --- OpenBSD 5.4 NAT regenerates checksums as follows: --- pf.c 1.863 (post OPENBSD_5_4) --- Assuming an AF_INET <-> AF_INET TCP connection. On initial rule match: pf_test_rule() 3445: pf_translate() 3707: pf_change_ap() 1677: PF_ACPY [= pf_addrcpy()] 3461: pf_cksum() 6775: pd->hdr.tcp->th_sum = 0; <--- checksum zeroed m->m_pkthdr.csum_flags |= M_TCP_CSUM_OUT <--- flagged for recalculation (if orig checksum good) On s
OBSD 5.4 and OpenLDAP
Hi folks! I would like to setup a OpenLDAP server using OpenBSD and the ports collection. I wonder if the current OpenLDAP in the ports is still broken ? Do it supports mdb/hdb/bdb ? Thanks a lot. gustavo.
Re: OBSD 5.4 and OpenLDAP
Why do you say it is still broken? I am running openldap-client-2.4.35p1 open-source LDAP software (client) openldap-server-2.4.35p2 open-source LDAP software (server) on OpenBSD 5.4 without any problems. The package works beautifully, works with samba, horde, etc., far better than anything else out there. I am using the following: # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_bdb.la Quoting Friedrich Locke : Hi folks! I would like to setup a OpenLDAP server using OpenBSD and the ports collection. I wonder if the current OpenLDAP in the ports is still broken ? Do it supports mdb/hdb/bdb ? Thanks a lot. gustavo. Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited vsan...@foretell.ca - This message was sent using ForeTell-POST 4.9