Re: open BSD + enterprise 250 don't work

2006-05-23 Thread Adam D. Morley
On Tue, May 23, 2006 at 07:46:52PM -0500, Jose Hugo Barradas Culebro wrote:
[snip]
> 
> this is an image of where the installation gets frozen.
> 
> http://i81.photobucket.com/albums/j225/ddtrebel/DSC05922.jpg

Does the system hang at "pcons at mainbus0 not configured" for a bit and
then display (sluggishly) and then eventually the rest?  I've noticed 
similar problems on Netra AC200/Sun Fire V120, but only with recent
OpenBoot/PROM patches.  Our V100s don't seem to be affected.  Try:

1. Set autoboot to false.
2. pull all USB devices (including keyboard, mouse)
3. pull out extra PCI cards
4. attach a serial console to ttya
5. cold-boot the server by attaching the power cord & key = on
6. at the ok prompt, boot the cdrom manually

I've found this to reliably work with our V120s and recent PROM patches.
If that works, you are seeing the same problem I see.  I'm
semi-conviced it's a PROM bug, as other OpenBSD users don't see similar
problems with older version of the PROM on AC200s/V120s.

Let me know how that goes.  I'm interested, as I see similar problems at
times.

-- 
adam



Re: Good, managed, GigE switch?

2006-05-10 Thread Adam D. Morley
On Wed, May 10, 2006 at 04:27:36PM -0500, Kevin wrote:
> On 5/10/06, Christian Weisgerber <[EMAIL PROTECTED]> wrote:
> >That's an "unmanaged switch".  It does not support VLANs/QoS, which
> >the original poster requested.
> 
> At the office, we use the Cisco 35(08|24|48) and Xl.  No complaints.
> Friends use (cheaper) rebadged Cajun switches,  also no complaints.

I can second the 3548XLs, as I've used them since ~2000.  They are a wee
dated when it comes to features in IOS vs. newer switches
(understandably so).  They are EOL'd, so security patches will
die sooner than new switches.

I have lately been using the 3750Gs (24/48port GigE), and I like them.
They are horrendously overpriced, but their functionality is good.  They
do require quite a lot of options to configure the ports securely
against layer two and spanning-tree attacks.  See:

http://www.blackhat.com/presentations/bh-usa-02/bh-us-02-convery-switches.pdf

for more information.

-- 
adam



Re: problem with LSI Fibre Channel MPT AMD64 OpenBSD 3.9-current

2006-04-27 Thread Adam D. Morley
On Tue, Apr 25, 2006 at 11:16:15AM -0600, Diana Eichert wrote:
> On Fri, 21 Apr 2006, Marco Peereboom wrote:
> 
> > So I really meant SC->LC.
> 
> Marco
> 
> Did anyone ever pony up a cable for you?

Marco has a box o' cables on the way as we speak, a mix of:

SC->SC
SC->LC
LC->LC

Along with some qlogic fibre cards (the new, cheap QLA210s).

-- 
adam



Re: Best WAN Adaper?

2006-04-21 Thread Adam D. Morley
On Fri, Apr 21, 2006 at 10:36:27AM +0200, Toni Mueller wrote:
> Hello,
> 
> On Wed, 19.04.2006 at 12:57:16 +0100, tony sarendal <[EMAIL PROTECTED]> wrote:
> > On 19/04/06, Toni Mueller <[EMAIL PROTECTED]> wrote:
> > > Anyway, if someone of you comes across good E3 cards, please drop me a
> > > note.  Otherwise, try to persuade your carrier to give you Ethernet.
> > 
> > What about using Ethernet to T3/E3 converters instead ?
> > That way you don't need funky cards in the openbsd box.
> 
> unfortunately, there appears to be no standard line encoding for E3
> lines, so if you want to have E3-Ethernet converters, you must use them
> in pairs, on both ends of the line. This rules out having eg your E3
> terminating somewhere inside an STM1/4/... trunk on the other side, but
> many carriers only offer this kind of setup. So you're almost
> guaranteed to have a non-working line if they have, say, a Cisco 12000
> on their end where your line terminates inside a trunk, and you have
> the simple fiber with only that one E3 incorporated. I've been told
> that the situation improves quite a bit when you have STM1 instead:
> There, a standard exists, but it doesn't appear to be widely tested if
> it actually works.

FWIW: if you're in Qwest-land, you can now get up to 20mbps delivered as
copper ethernet.  They use a bucket of bonded pairs to do it, but it can
supposedly be done.  I looked at it a while ago, but it was somewhat
pricey when I only needed 3mbps.  ;-)

Anything higher than 20mbps seems to require fibers.

-- 
adam



Re: OpenBSD/Linux centralized authentication

2006-03-19 Thread Adam D. Morley
On Sun, Mar 19, 2006 at 10:42:53AM +0400, Bruno Carnazzi wrote:
>   Hi misc,
> 
> At work, we are running a Microsoft Active Directory for our Windows
> Domain, who mainly provided Windows Desktop for our customers and
> centralized authentication. We have also several OpenBSD & Linux boxes
> for some DNS, SFTP, Squid, CVS and also several Web-apps. We'd like to
> centralize these Unix authentication... Is there a way to authenticate
> directly over a MS Domain Controller ? How can this be achieved
> (Kerberos, LDAP..?) ? Also, is it a good idea ? :) What are the
> alternatives (building an OpenLDAP server, Kerberos, (we don't wan't
> NIS !)) ?

MS AD provides MIT-ish KDC support, or so I hear.  I've never used it
from the UNIX side, but I do know that Windows clients will willingly
talk to a UNIX KDC, and I'm told the reverse is true.  Authenticating
Windows clients from OpenBSD Heimdal works just lovely.

Microsoft does provide a services for unix package, but it uses NIS last
time I looked at it.

Your problems will most likely occur when mapping possibly long principal
names on Windows to the UNIX side, or getting the data from LDAP and
populating (either using scripts or an nss_ldap module) the user
accounts on the client side.

If you have simple accont names on Windows, it's fairly straightforward
to use PAM or login to authenticate the password.  Google will find you
many resources on setting this up.

-- 
adam



Re: Strange carp issues

2006-03-17 Thread Adam D. Morley
On Fri, Mar 17, 2006 at 03:41:01PM -0500, Steven S wrote:
> Adam D. Morley wrote:
> > On Fri, Mar 17, 2006 at 02:35:55PM -0500, Steven S wrote:
> >> Adam D. Morley wrote:
> ...
> >> Thanks, this is helpful.  The settings on the FW's are as above.  An
> >> incorrect setting (above) would seem to make it not work -- as
> >> opposed to 
> > 
> > Ok.  But mine works and yours doesn't?
> > 
> >> what I'm seeing.  Sometimes FW2 takes over as MASTER for some
> >> interfaces, but FW1 never moves to BACKUP.  I do have
> >> net.inet.carp.preempt=1 set on FW1, but not FW2.
> > 
> > You're supposed to set preempt on both, iirc.
> 
> With both firewalls set to preempt=1 I had a common DMZ switch get shut-off.
> Both FW's went to a carp skew of 240.  They had a MASTER fight.  By setting
> one with preempt=1 and the other with preempt=0, I avoid this.  

This is likely because one of the firewalls does not have a pass rule for
carp packets.  I have seen this happen before, especially when adding a
new carp interface and not updating ext_ints.

> 
> >> As another experiment I moved advbase on FW2 to '2' for all carps,
> >> but the 
> > 
> > base is how often.  skew is priority.
> 
> Sort of...  'man ifconfig' Says,

Sort of, yes, but for the purposes of pre-empted pf-walls, it's a very
convinent simplification.

> 
> "Taken together the advbase and advskew indicate how frequently, in seconds,
> the host will advertise the fact that it considers itself master of the
> virtual host.  The formula is advbase + (advskew / 256).  If the master does
> not advertise within three times this interval, this host will begin
> advertising as master."

Yes, I have read man ifconfig.  ;-)

> 
> So if I set FW1 with 1/0 and FW2 at 2/180, FW1 advertises every one second.
> If FW2 hasn't heard a carp advertisement in 2.7*3=8.1 seconds it will take
> over.  When FW1 returns, it will start advertising once/sec.  As noted in my
> OP, this doesn't seem to happen on my FW pair.

Well, FW1 expects FW2 to advertise as master within 3 seconds, and it's
advertising every 2.7 seconds.  This is pretty close, though it should be
more than enough time.  It would be "irrelevant" if one had default master
status (preempt on on both), but that's not the case in your setup.

Out of curiosity, why are you twiddling advbase?  Do you have some 
high-latency serial lines in there or something?  Are you attempting to
get longer detection intervals in case fw1 is not actually down, but fw2
thinks it is?  If it's the later, then that's not what it's for.

Personally, I would keep advbase the same on both hosts and twiddle advskew, 
set preempt (on both), and see what happens.  If something goes wrong, then 
it's likely a missing pass rule for carp packets.

-- 
adam



Re: Strange carp issues

2006-03-17 Thread Adam D. Morley
On Fri, Mar 17, 2006 at 12:48:49PM -0800, Jon Simola wrote:
> On 3/17/06, Adam D. Morley <[EMAIL PROTECTED]> wrote:
> 
> > > As another experiment I moved advbase on FW2 to '2' for all carps, but the
> >
> > base is how often.  skew is priority.
> 
> No, advbase is integer seconds between advertisements, advskew is
> fractional seconds. Taken together, advbase and advskew are an 8.8 bit
> fixed point number allowing you to specify advertisment intervals
> between 4ms and 255.996s (in theory anyways, setting advskew to 240 or
> above is used with preempting as a magic number).

Of course.  However, for many, the combination of both advbase and
advskew is confusing, and a simplication is "easier" for them to grasp.
Especially when trying to explain pre-empting.  Ie: the average user won't
need advbase, and so explaining advskew as "priority" (when in fact is
is not) makes it "easier" to understand.  For example, when a user is
following:

http://www.countersiege.com/doc/pfsync-carp/

explaining advskew as a "priority" often makes people grasp the concept
faster, and then once it "works," they can go, "hmm...oh yes, the man
page!"

-- 
adam



Re: Strange carp issues

2006-03-17 Thread Adam D. Morley
On Fri, Mar 17, 2006 at 02:35:55PM -0500, Steven S wrote:
> Adam D. Morley wrote:
> ...
> > Have you checked:
> > 
> > - carp settings in sysctl?
> > - carp pass rules (and ordering) in pf.conf (if you have default
> > deny)? 
> > - that you have advskew set "right" on the backup firewall?
> > 
> > # grep carp /etc/sysctl.conf
> > net.inet.carp.allow=1   # allow incoming CARP packets
> > net.inet.carp.preempt=1 # failover all CARP
> > interfaces if one fails
> > 
> > # grep carp /etc/pf.conf
> > pass quick on $ext_ints proto carp keep state
> > pass on $int_phys proto carp keep state
> > pass on $int_vlan proto carp keep state
> > 
> > # cat /etc/hostname.carp1
> > vhid 1 advskew 100 pass 
> > inet XXX 0xff00
> 
> Thanks, this is helpful.  The settings on the FW's are as above.  An
> incorrect setting (above) would seem to make it not work -- as opposed to

Ok.  But mine works and yours doesn't?

> what I'm seeing.  Sometimes FW2 takes over as MASTER for some interfaces,
> but FW1 never moves to BACKUP.  I do have net.inet.carp.preempt=1 set on
> FW1, but not FW2.  

You're supposed to set preempt on both, iirc.

> 
> As another experiment I moved advbase on FW2 to '2' for all carps, but the

base is how often.  skew is priority.

-- 
adam



Re: Strange carp issues

2006-03-17 Thread Adam D. Morley
On Fri, Mar 17, 2006 at 07:59:35PM +0100, Henning Brauer wrote:
> * Steven S <[EMAIL PROTECTED]> [2006-03-17 19:10]:
> > beginning to think it might be a component of the number of carp interfaces
> 
> unlikely.
> <[EMAIL PROTECTED]>  $ ifconfig | grep '^carp' | wc -l 
>   15 
> and growing.
> and yes, that is real-world production use.

I would agree that number of carp interfaces doesn't matter:

# ifconfig |grep ^carp |wc -l
  23

This is real-world also, with many of the carp interfaces layered on top
of VLANs.  Intel dual GE cards.

Have you checked:

- carp settings in sysctl?
- carp pass rules (and ordering) in pf.conf (if you have default deny)?
- that you have advskew set "right" on the backup firewall?

# grep carp /etc/sysctl.conf
net.inet.carp.allow=1   # allow incoming CARP packets
net.inet.carp.preempt=1 # failover all CARP interfaces if one fails

# grep carp /etc/pf.conf
pass quick on $ext_ints proto carp keep state
pass on $int_phys proto carp keep state
pass on $int_vlan proto carp keep state

# cat /etc/hostname.carp1
vhid 1 advskew 100 pass 
inet XXX 0xff00

-- 
adam