Re: I haven't heard of anyone else with this screen problem
On Mar 05 15:53:06, glis...@witworx.com wrote: > When booting and the screen goes to its 34 line 85 column mode, the > text mode fits into 30cm wide and 22cm high at the top left corner of a 38cm > wide 30cm high screen. With current/amd64 on an Intel Pineview video (full dmesg below) my text console becomes 36 rows x 106 columns, which takes up the whole width of the screen, but leaves about ten more rows that could fit to the height, like this: ++ || || | text console | || || || ++ || |unused | ++ This does not happen on e.g. current/amd64 running on a Thinkpad T400. Is this about the Intel Pineview gfx? What can I do to help debug it? Jan OpenBSD 5.5 (GENERIC.MP) #313: Mon Mar 3 17:12:14 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80 real mem = 1038864384 (990MB) avail mem = 1002651648 (956MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe4410 (25 entries) bios0: vendor Intel Corp. version "MOPNV10J.86A.0175.2010.0308.0620" date 03/08/2010 bios0: Intel Corporation D510MO acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET SSDT acpi0: wakeup devices SLPB(S4) PS2M(S4) PS2K(S4) UAR1(S4) UAR2(S4) P32_(S4) ILAN(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) EHCI(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) Atom(TM) CPU D510 @ 1.66GHz, 1666.94 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu0: 512KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu0: mwait min=64, max=64, C-substates=0.1.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.69 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu1: 512KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.69 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu2: 512KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.69 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu3: 512KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 8 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 5 (P32_) acpiprt1 at acpi0: bus 0 (PCI0) acpiprt2 at acpi0: bus 1 (PEX0) acpiprt3 at acpi0: bus 2 (PEX1) acpiprt4 at acpi0: bus 3 (PEX2) acpiprt5 at acpi0: bus 4 (PEX3) acpicpu0 at acpi0: C1, PSS acpicpu1 at acpi0: C1, PSS acpicpu2 at acpi0: C1, PSS acpicpu3 at acpi0: C1, PSS acpibtn0 at acpi0: SLPB pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02 vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1280x800 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/8111D (0x2800), msi, address 00:27:0e:07:09:9f rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01: msi pci3 at ppb2 bus 3 ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: msi pci4 at ppb3 bus 4 uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 8 int 23 uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 8 int 19 uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 8 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801GB
NTP timeout question
Using OpenNPTD from stable. Syncing to two redundant satellite receivers that provide ntp service and also radio programming. The satellite receivers tend to lose time sync occasionally, but regain it fairly quickly. NPTD reports: reply from 192.168.1.102: not synced (alarm), next query 3156s Is there a way to make ntpd ignore these alarms, or perhaps set them to a time less than fifty minutes (average)? -- Jeff Simmons jsimm...@goblin.punk.net Simmons Consulting - Network Engineering, Administration, Security "You guys, I don't hear any noise. Are you sure you're doing it right?" -- My Life With The Thrill Kill Kult
Re: IPSec Packet Loss Help
> I had to disable monitoring of the internal interfaces of both remote
> firewalls, as it killed the VPN when you ping'ed the backup firewall. The
> packets get there, but the reply is sent back directly from the backup and
> not via the master.
>
> To fix that I added a NAT rule, and could then monitor and connect to the
> internal interfaces of both remote firewalls again..
> (These pf.conf examples and files below are from our remote office
> firewalls. carp0 = external, carp1 = internal);
> match out on $if_lan from { $hq_lan } to ($if_lan:network) nat-to (carp1)
>
> pass in quick on enc0 proto ipencap from { $ext_ip_hqfw } to { (carp0) }
> keep state (if-bound)
> pass in quick on enc0 from { $hq_lan } to { $if_lan:network } keep state
> (if-bound)
>
> pass quick on $if_lan from { $hq_lan, (carp1) } to { $if_lan:network } queue
> (_wan_vpn,_wan_pri) set prio (2,5)
I currently don't have any queuing on this link, but my rules look
pretty close to the same here. tcpdump -nei pflog0 doesn't show any
blocks for my traffic with 'block in log' set, so I don't think PF is
getting in the way.
Though, as you mention above, if the tunnel drops *because* I am hitting
this internal address, this would be a problem.
> PS; Also don't forget to restrict the MTU of VPN traffic so it doesn't
> fragment (needed on both sides naturally);
> match in on $if_lan proto { tcp, udp, icmp } from { $if_lan:network } to {
> $hq_lan } scrub (no-df max-mss 1400)
> set skip on $if_pfsync
I have set this, though I don't really know how to verify if its working
like expected. If I tcpdump the internal carp interface, and ping
through the tunnel and to a device on the other side, I see the packets
traverse the link. If I increase the ping size (-s 1500) I see
fragmentation, but that doesn't really tell me that the rule is working,
does it? Maybe I don't understand what that is supposed to be doing.
> >>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.
>
> Yea they sort the startup, shutdown and also ensure a prompt the failover. I
> wrote them during 5.2 so may not be so important but they add a level of
> failsafe otherwise.
> Keeping the tunnel up should simply be a case of making sure the backup
> *never* sends encaped packets itself..
Oh, I missed this last read through. What does this do? Why? I assume
this is the reason for the route on the firewall machine to use the
local internal carp for the remote network.
I understand the reason to route the packet to the internal carp
interface on the backup, but on the primary I am unsure. So where
172.16.32.1 is the internal carp, I have a route on both the master and
the backup.
route add 172.16.0.0/24 172.16.32.1
Assuming that 172.16.0.0/24 is the remote network.
> >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.
> >
>
> No, none at all. Our tunnels are *really* stable. I can reboot a firewall
> and the tunnel only stops for a few seconds before switching over
> gracefully.
I really want to be able to say the same for these.
> /etc/sasyncd.conf
> peer 192.168.30.253 <- The other IP on the PFSYNC interface (cable directly
> connected between firewalls)
> interface carp0
> group carp
> listen on 192.168.30.252 inet port 500 <- This PFSYNC IP etc..
> sharedkey 0x
> flushmode startup
> control isakmpd
I now have exactly this, except where the options here are specified as
default in the manpage. I left off control for example, as isakmpd is
default, as is group carp.
> /etc/isakmpd.conf
> [general]
> listen-on=,
I've added this for my install and verified that ports are listening
only on those addresses.
> /etc/ipsec.conf
> # Macros
> local_gw=""
> local_net=""
> remote_gw=""
> remote_net=""
>
> ike dynamic esp from $local_net to $remote_net \
> local $local_gw peer $remote_gw \
> main auth hmac-sha2-256 enc aes group modp1024 \
> quick auth hmac-sha2-256 enc aes group modp1024 \
> srcid $local_gw dstid $remote_gw \
> psk
The only thing I was missing here was the srcid and dstid, but that
didn't seem to make a difference.
So now I have the sasyncd and pfsync both going over a directly
connected link, and sasyncd is only listening on that interface address,
as well as 'set skip' on the interface in pf. All seems like what you
have.
Just for troubleshooting, I've only added the sasyncd to one side, since
without HA is stable, I'd like to introduce one set of change at a time
for testi
Re: Broadcom BCM5805 crypto accelerator
On 2014-03-07, Andy Hayward wrote: > Cleaning out my firewall box (Atom 330 based) before upgrading, and I > noticed it had a BCM5805 crypto accelerator card installed. Is there any > reason to keep this these days (even an an entropy source for random(4)), > or should I just recycle it as a door stop? Looking over ubsec(4), I'd say its hardware random generator is indeed the only useful function left. Since you already have the card in place, why throw it away? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: IPSec Packet Loss Help
On Fri, Mar 07, 2014 at 04:35:45PM +, Andy wrote:
> Hi
>
> On Thu 06 Mar 2014 23:03:58 GMT, Zach Leslie wrote:
> >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.
> >
>
> encap (I tried to add a route for the remote net on the firewall pointing to
> the internal switch, which would bounce the packet back to the CARP IP, thus
> getting packets from the backup to the master and over the VPN. But it
> doesn't work, the encap route is used first and so the tunnel drops).
I suppose I should be more explicit. For packets generated by the host,
it seems to use the inet routing table. Perhaps thats because the
source IP is not in the flow.
> >>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 had to disable monitoring of the internal interfaces of both remote
> firewalls, as it killed the VPN when you ping'ed the backup firewall. The
> packets get there, but the reply is sent back directly from the backup and
> not via the master.
What do you mean killed the VPN? As in you saw packet loss, or the
tunnel went down completely, or just that those packets did not return.
> To fix that I added a NAT rule, and could then monitor and connect to the
> internal interfaces of both remote firewalls again..
> (These pf.conf examples and files below are from our remote office
> firewalls. carp0 = external, carp1 = internal);
> match out on $if_lan from { $hq_lan } to ($if_lan:network) nat-to (carp1)
>
> pass in quick on enc0 proto ipencap from { $ext_ip_hqfw } to { (carp0) }
> keep state (if-bound)
> pass in quick on enc0 from { $hq_lan } to { $if_lan:network } keep state
> (if-bound)
>
> pass quick on $if_lan from { $hq_lan, (carp1) } to { $if_lan:network } queue
> (_wan_vpn,_wan_pri) set prio (2,5)
I've not implemented this NAT yet, simply because the packets in my case
do get returned. I have a route on both firewalls to the remote network
to point at the carp address shared between them. Though your mention
of the VPN going down sounds familiar.
> PS; Also don't forget to restrict the MTU of VPN traffic so it doesn't
> fragment (needed on both sides naturally);
> match in on $if_lan proto { tcp, udp, icmp } from { $if_lan:network } to {
> $hq_lan } scrub (no-df max-mss 1400)
> set skip on $if_pfsync
I'll add this shortly and test.
> Yea they sort the startup, shutdown and also ensure a prompt the failover. I
> wrote them during 5.2 so may not be so important but they add a level of
> failsafe otherwise.
> Keeping the tunnel up should simply be a case of making sure the backup
> *never* sends encaped packets itself..
Committing them to source seems reasonable if they are an improvement on
what is there.
> /etc/sasyncd.conf
> peer 192.168.30.253 <- The other IP on the PFSYNC interface (cable directly
> connected between firewalls)
> interface carp0
> group carp
> listen on 192.168.30.252 inet port 500 <- This PFSYNC IP etc..
> sharedkey 0x
> flushmode startup
> control isakmpd
My sasyncd.conf looks different, so I'm going to try some of this now.
Enabling sasyncd and adding -S to the isamkpd causes serious instability
right now. Disabling it makes everything stable again, so I'm hoping
its just a configuration issue. So this means that you have PFsync and
sasyncd going over the same directly attached interfaces, correct?
I'll report back when I've implemented the changes.
Thanks for the advice.
--
Zach
Re: ypldap 1024 character limit on groups?
> I see. Wow, that is a HUGE bug. Such maximum line lengths have been commonplace in Unix forever. This is not an OpenBSD-introduced problem; it is just something that has not yet been improved. Improvements come when people try to push forward along the curve. People like you...
Re: ypldap 1024 character limit on groups?
On Mar 6, 2014, at 3:24 PM, Philip Guenther wrote: > 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 I see. Wow, that is a HUGE bug. Unless there is some workaround, that essentially means OpenBSD is not suitable for use in any sort of directory environment, unless it is very small. I mean, I only have about 300 users in my directory (about 1/3 of the total company), split between two groups, and ypldap only shows about 2/3 of each group, or about 100 people. You could MAYBE manage 200 if you used shorter usernames. But maybe we're just weird, and no normal company puts more than 100 people in a group :-) In any case, thanks for the information. I guess I'll start looking at other OS options. That stinks - I like OpenBSD. --- 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: IPSec Packet Loss Help
Hi
On Thu 06 Mar 2014 23:03:58 GMT, Zach Leslie wrote:
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.
encap (I tried to add a route for the remote net on the firewall
pointing to the internal switch, which would bounce the packet back to
the CARP IP, thus getting packets from the backup to the master and
over the VPN. But it doesn't work, the encap route is used first and so
the tunnel drops).
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 had to disable monitoring of the internal interfaces of both remote
firewalls, as it killed the VPN when you ping'ed the backup firewall.
The packets get there, but the reply is sent back directly from the
backup and not via the master.
To fix that I added a NAT rule, and could then monitor and connect to
the internal interfaces of both remote firewalls again..
(These pf.conf examples and files below are from our remote office
firewalls. carp0 = external, carp1 = internal);
match out on $if_lan from { $hq_lan } to ($if_lan:network) nat-to
(carp1)
pass in quick on enc0 proto ipencap from { $ext_ip_hqfw } to { (carp0)
} keep state (if-bound)
pass in quick on enc0 from { $hq_lan } to { $if_lan:network } keep
state (if-bound)
pass quick on $if_lan from { $hq_lan, (carp1) } to { $if_lan:network }
queue (_wan_vpn,_wan_pri) set prio (2,5)
PS; Also don't forget to restrict the MTU of VPN traffic so it doesn't
fragment (needed on both sides naturally);
match in on $if_lan proto { tcp, udp, icmp } from { $if_lan:network }
to { $hq_lan } scrub (no-df max-mss 1400)
set skip on $if_pfsync
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.
Yea they sort the startup, shutdown and also ensure a prompt the
failover. I wrote them during 5.2 so may not be so important but they
add a level of failsafe otherwise.
Keeping the tunnel up should simply be a case of making sure the backup
*never* sends encaped packets itself..
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.
No, none at all. Our tunnels are *really* stable. I can reboot a
firewall and the tunnel only stops for a few seconds before switching
over gracefully.
/etc/sasyncd.conf
peer 192.168.30.253 <- The other IP on the PFSYNC interface (cable
directly connected between firewalls)
interface carp0
group carp
listen on 192.168.30.252 inet port 500 <- This PFSYNC IP etc..
sharedkey 0x
flushmode startup
control isakmpd
/etc/isakmpd.conf
[general]
listen-on=,
/etc/ipsec.conf
# Macros
local_gw=""
local_net=""
remote_gw=""
remote_net=""
ike dynamic esp from $local_net to $remote_net \
local $local_gw peer $remote_gw \
main auth hmac-sha2-256 enc aes group modp1024 \
quick auth hmac-sha2-256 enc aes group modp1024 \
srcid $local_gw dstid $remote_gw \
psk
/etc/rc.d/isakmpd.conf;
#!/bin/sh
#
# $OpenBSD: isakmpd,v 1.1 2011/07/06 18:55:36 robert Exp $
daemon="/sbin/isakmpd"
. /etc/rc.d/rc.subr
pexp="isakmpd: monitor \[priv\]"
rc_pre() {
[ X"${sasyncd_flags}" != X"NO" ] && \
daemon_flags="-S ${daemon_flags}"
return 0
}
rc_stop() {
if [ `ifconfig | grep "status: master" | wc -l` > 0 ]; then
ipsecctl -d -f /etc/ipsec.conf; fi
sleep 1
if [ `ifconfig | grep "status: master" | wc -l` > 0 ]; then
ipsecctl -d -f /etc/ipsec.conf; fi
if [ `ifconfig | grep "status: master" | wc -l` > 0 ]; then
ipsecctl -F -f /etc/ipsec.conf; fi
pkill -f "^${pexp}"
}
rc_cmd $1
/etc/rc.d/sasyncd
#!/bin/sh
#
# $Open
Broadcom BCM5805 crypto accelerator
Cleaning out my firewall box (Atom 330 based) before upgrading, and I noticed it had a BCM5805 crypto accelerator card installed. Is there any reason to keep this these days (even an an entropy source for random(4)), or should I just recycle it as a door stop? Thanks.
Re: openldap password fails to update
On 03/07/2014 04:22 AM, Stéphane Guedon wrote:
# ldappasswd -x -v -D "uid=test,ou=users,dc=22decembre,dc=eu" \
-w somesecret -s anothersec
ldap_initialize( )
Result: Other (e.g., implementation specific) error (80)
Additional info: password hash failed
I'm sorry, it's not clear that this is an OpenBSD problem. See, for
example,
http://www.openldap.org/lists/openldap-technical/200902/msg00186.html
There's another thing strange, maybe related to the problem :
slappasswd never gives the same result !
# slappasswd
New password:
Re-enter new password:
{SSHA}8ip4+k3gVAN6Gggf2szhJxo052sI3Fyc
# slappasswd
New password:
Re-enter new password:
{SSHA}JvduTI/JAX1G9AhtlCYEjNHl/6DbE6hs
The whole point of salting is to make the hash different each time. A
random salt is used to alter the hash and then that salt is added to the
end of the hashed string before being base64-encoded to give you the
hash you see.
--
Matthew Weigel
hacker
unique & idempot . ent
openldap password fails to update
Hello everybody.
I am currently finishing my openbsd server. Most of installation gone
pretty well :-).
I run now in openldap. I successfully installed the server and
launched it in chroot for security.
My problem is weird : using ldapadd, I can add peoples and stuff.
ldapadd -x -D "cn=admin,dc=22decembre,dc=eu" -w secret -f stef.ldif
adding new entry "uid=test,ou=users,dc=22decembre,dc=eu"
But when I try to change this user password it fails :
# ldappasswd -x -v -D "uid=test,ou=users,dc=22decembre,dc=eu" \
-w somesecret -s anothersec
ldap_initialize( )
Result: Other (e.g., implementation specific) error (80)
Additional info: password hash failed
and when looking in logs I don't see why it fails !
Mar 7 10:29:35 blackblock slapd[26351]: => slap_access_allowed: auth
access granted by auth(=xd)
Mar 7 10:29:35 blackblock slapd[26351]: => access_allowed: auth
access granted by auth(=xd)
Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=0 BIND
dn="uid=test,ou=users,dc=22decembre,dc=eu" mech=SIMPLE ssf=0
Mar 7 10:29:35 blackblock slapd[26351]: do_bind: v3 bind:
"uid=test,ou=users,dc=22decembre,dc=eu" to
"uid=test,ou=users,dc=22decembre,dc=eu"
Mar 7 10:29:35 blackblock slapd[26351]: send_ldap_result: conn=1014
op=0 p=3
Mar 7 10:29:35 blackblock slapd[26351]: send_ldap_result: err=0
matched="" text=""
Mar 7 10:29:35 blackblock slapd[26351]: send_ldap_response: msgid=1
tag=97 err=0
Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=0 RESULT tag=97
err=0 text=
Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on 1
descriptor
Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on:
Mar 7 10:29:35 blackblock slapd[26351]: 22r
Mar 7 10:29:35 blackblock slapd[26351]:
Mar 7 10:29:35 blackblock slapd[26351]: daemon: read activity on 22
Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=6
active_threads=0 tvp=NULL
Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=7
active_threads=0 tvp=NULL
Mar 7 10:29:35 blackblock slapd[26351]: connection_get(22)
Mar 7 10:29:35 blackblock slapd[26351]: connection_get(22): got
connid=1014
Mar 7 10:29:35 blackblock slapd[26351]: connection_read(22): checking
for input on id=1014
Mar 7 10:29:35 blackblock slapd[26351]: op tag 0x77, time 1394184575
Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on 1
descriptor
Mar 7 10:29:35 blackblock slapd[26351]: daemon: waked
Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=6
active_threads=0 tvp=NULL
Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=7
active_threads=0 tvp=NULL
Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=1 do_extended
Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=1 EXT
oid=1.3.6.1.4.1.4203.1.11.1
Mar 7 10:29:35 blackblock slapd[26351]: do_extended:
oid=1.3.6.1.4.1.4203.1.11.1
Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=1 PASSMOD new
Mar 7 10:29:35 blackblock slapd[26351]:
bdb_dn2entry("uid=test,ou=users,dc=22decembre,dc=eu")
Mar 7 10:29:35 blackblock slapd[26351]: send_ldap_extended: err=80
oid= len=0
Mar 7 10:29:35 blackblock slapd[26351]: send_ldap_response: msgid=2
tag=120 err=80
Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=1 RESULT oid=
err=80 text=password hash failed
Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on 1
descriptor
Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on:
Mar 7 10:29:35 blackblock slapd[26351]: 22r
Mar 7 10:29:35 blackblock slapd[26351]:
Mar 7 10:29:35 blackblock slapd[26351]: daemon: read activity on 22
Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=6
active_threads=0 tvp=NULL
Mar 7 10:29:35 blackblock slapd[26351]: connection_get(22)
Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=7
active_threads=0 tvp=NULL
Mar 7 10:29:35 blackblock slapd[26351]: connection_get(22): got
connid=1014
Mar 7 10:29:35 blackblock slapd[26351]: connection_read(22): checking
for input on id=1014
Mar 7 10:29:35 blackblock slapd[26351]: op tag 0x42, time 1394184575
Mar 7 10:29:35 blackblock slapd[26351]: ber_get_next on fd 22 failed
errno=0 (Undefined error: 0)
Mar 7 10:29:35 blackblock slapd[26351]: connection_read(22): input
error=-2 id=1014, closing.
Mar 7 10:29:35 blackblock slapd[26351]: connection_closing: readying
conn=1014 sd=22 for close
Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on 1
descriptor
Mar 7 10:29:35 blackblock slapd[26351]: daemon: waked
Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=6
active_threads=0 tvp=NULL
Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=7
active_threads=0 tvp=NULL
Mar 7 10:29:35 blackblock slapd[26351]: connection_close: deferring
conn=1014 sd=22
Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=2 do_unbin
