Re: CARP Cold Spare

2021-09-25 Thread Don Tek
Unsure what the power draw is on these guys yet, they just got them.  They have 
redundant 450W Platinum power supplies.

The "new" servers are completely overkill for the application, but this is a 
work-with-what's-available situation.  They got these free from a friend and 
don't want to spend on new hardware, otherwise I'd just get them something 
"smaller" and supremely efficient.

We already have redundant UPS's.  With the 3 servers previously (main VM 
servers and 1 now-dead firewall) attached to battery-backed power, we were 
getting roughly 3.5 hours of runtime before UPS drop.  Sometimes minutes can 
matter with these blackouts.

I also want that with the one machine not running, it's not incurring any wear 
or tear just for the sake of hot failover.

I've got no talent on site, so in the event of a hardware or file system 
failure, It's an extremely tedious experience for me to walk someone there 
through swapping hardware, wiring, or reinstalling an operating system.  So, 
I'm looking for that turn-this-one-off-and-this-one-on recovery option, without 
the need to fiddle with any hardware.  If this works the way I want, the only 
single point of failure will be their cable modem, and Comcast can handle 
replacing that.

Option B is to just have identical configurations and have them need to swap 
the network wiring as part of the failover.  Will still prevent the days of 
downtime we're incurring now due to this failure, but not as simple for them, 
if the CARP solution is solid.

> On Sep 25, 2021, at 10:25 AM, leonard  wrote:
> 
> 
> What is the power draw? I use a 1500 VA apc backups with 6 outlets on ups and 
> 5 on surge protection. As long as your total draw is less than 1200 VA, for < 
> $200 canadian you have a cheap simple solution. Just put on on the ups side 
> and the other on the surge suppressor side. Or buy 2.
> 
> 
> 
> leonard@on the road
> 
> 
>  Original message 
> From: Don Tek 
> Date: 2021-09-25 11:40 (GMT-05:00)
> To: jslee 
> Cc: misc@openbsd.org
> Subject: Re: CARP Cold Spare
> 
> I'm not sure why the hardware matters, but the two machines are a couple HP 
> 1U Gen 8 Xeon servers.  Suffice to say, they are identical and have supported 
> hardware configurations for OpenBSD.
> 
> Of course I _could_ run one off direct power, but it would be a terrible 
> idea.  The location is notorious for power surges, blips that are enough to 
> reboot servers and several-second brown-outs.  So, not connected to the UPS 
> is just asking for damages.
> 
> They experience multi-hour blackouts what seems like once a month; this is 
> where the desire to limit the draw on the UPS's comes from.  To ensure we 
> make it through without having to shut down.
> 
> Remote access is of primary concern, both for me for support, since I'm 
> geographically far enough away that being on-site is not feasible, and to the 
> customer, who just wants to stay home and work on systems in the office.
> 
> Configurations on the servers almost never change (simple firwall), so 
> besides having to run a quick syspatch and reboot once at time of failover, I 
> don't see maintenance being so bad.  I keep config files backed-up otherwise 
> centrally for quick restore to the running box as well.
> 
> My primary concern here is if CARP / pfsync will have issues with the one 
> machine being down a majority of the time.  Based on the FAQ, I think not, 
> but have no practical experience.
> 
> > On Sep 25, 2021, at 3:00 AM, jslee  wrote:
> > 
> > Hi,
> > 
> > You haven’t said anything about your hardware platform, but could you run 
> > one of them on non-UPS power? Then you’d still have one online when (*not* 
> > if) the UPS fails, and also they’ll both normally be online for 
> > maintenance, syspatch, config changes etc
> > 
> > I do recall installing a pair of identical servers at the same time and 
> > having them both fail a year later within an hour of each other, both with 
> > seized CPU fans, so I am somewhat sympathetic to your idea. But I think the 
> > practical cost of maintenance may be rather high
> > 
> > John
> > 
> > 
> >> On Sat, 25 Sep 2021, at 08:13, Don Tek wrote:
> >> Would there be any ‘problem’ with configuring a 2-machine CARP setup 
> >> and then just keeping one machine powered-off until needed?
> >> 
> >> I realize this defeats live failover, but this is not a requirement for 
> >> my customer.
> >> 
> >> I just want them to be able to, in the event of a primary machine 
> >> failure, power-on the secondary and have it take over.  Logic here is 
> >> to otherwise not have the secondary sucking power off the UPS’s in the 
> >> event of a power failure, or in general.
> >> 
> >> Legit?
> 


Re: CARP Cold Spare

2021-09-25 Thread Don Tek
I'm not sure why the hardware matters, but the two machines are a couple HP 1U 
Gen 8 Xeon servers.  Suffice to say, they are identical and have supported 
hardware configurations for OpenBSD.

Of course I _could_ run one off direct power, but it would be a terrible idea.  
The location is notorious for power surges, blips that are enough to reboot 
servers and several-second brown-outs.  So, not connected to the UPS is just 
asking for damages.

They experience multi-hour blackouts what seems like once a month; this is 
where the desire to limit the draw on the UPS's comes from.  To ensure we make 
it through without having to shut down.

Remote access is of primary concern, both for me for support, since I'm 
geographically far enough away that being on-site is not feasible, and to the 
customer, who just wants to stay home and work on systems in the office.

Configurations on the servers almost never change (simple firwall), so besides 
having to run a quick syspatch and reboot once at time of failover, I don't see 
maintenance being so bad.  I keep config files backed-up otherwise centrally 
for quick restore to the running box as well.

My primary concern here is if CARP / pfsync will have issues with the one 
machine being down a majority of the time.  Based on the FAQ, I think not, but 
have no practical experience.

> On Sep 25, 2021, at 3:00 AM, jslee  wrote:
> 
> Hi,
> 
> You haven’t said anything about your hardware platform, but could you run one 
> of them on non-UPS power? Then you’d still have one online when (*not* if) 
> the UPS fails, and also they’ll both normally be online for maintenance, 
> syspatch, config changes etc
> 
> I do recall installing a pair of identical servers at the same time and 
> having them both fail a year later within an hour of each other, both with 
> seized CPU fans, so I am somewhat sympathetic to your idea. But I think the 
> practical cost of maintenance may be rather high
> 
> John
> 
> 
>> On Sat, 25 Sep 2021, at 08:13, Don Tek wrote:
>> Would there be any ‘problem’ with configuring a 2-machine CARP setup 
>> and then just keeping one machine powered-off until needed?
>> 
>> I realize this defeats live failover, but this is not a requirement for 
>> my customer.
>> 
>> I just want them to be able to, in the event of a primary machine 
>> failure, power-on the secondary and have it take over.  Logic here is 
>> to otherwise not have the secondary sucking power off the UPS’s in the 
>> event of a power failure, or in general.
>> 
>> Legit?



CARP Cold Spare

2021-09-24 Thread Don Tek
Would there be any ‘problem’ with configuring a 2-machine CARP setup and then 
just keeping one machine powered-off until needed?

I realize this defeats live failover, but this is not a requirement for my 
customer.

I just want them to be able to, in the event of a primary machine failure, 
power-on the secondary and have it take over.  Logic here is to otherwise not 
have the secondary sucking power off the UPS’s in the event of a power failure, 
or in general.

Legit?



Re: Checking Routes/Gateways For Good Connection

2010-08-30 Thread Don Tek

 On 8/29/2010 11:54 AM, Henning Brauer wrote:

when pf sees that packet it is outbound on em0. you are logging that
fact. then pf re-routes via em1. when pf sees it again on em1, you log
that fact.


My tcpdump output does not seem to confirm this.  For instance:

$ traceroute -m 4 -s 172.16.0.1 -n google.com

$ sudo tcpdump -n -e -ttt -i pflog0 host 172.16.0.1
tcpdump: listening on pflog0, link-type PFLOG
Aug 30 13:13:09.622700 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33435: udp 12 [ttl 1]
Aug 30 13:13:14.630584 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33436: udp 12 [ttl 1]
Aug 30 13:13:19.639902 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33437: udp 12 [ttl 1]
Aug 30 13:13:24.649161 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33438: udp 12
Aug 30 13:13:29.658493 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33439: udp 12
Aug 30 13:13:34.667819 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33440: udp 12
Aug 30 13:13:39.677161 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33441: udp 12
Aug 30 13:13:44.686542 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33442: udp 12
Aug 30 13:13:49.695834 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33443: udp 12
Aug 30 13:13:54.705161 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33444: udp 12
Aug 30 13:13:59.714426 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33445: udp 12
Aug 30 13:14:04.723664 rule 42/(match) pass out on em1: 172.16.0.1.58471 
> 209.85.225.104.33446: udp 12


Traceroute's defaults dictate a 5 second wait between probes and 3 
probes per hop.  I forced my max_ttl to 4 (hops).  I get exactly 12 
lines of log corresponding to (3 probes * 4 hops) and the log shows 5 
seconds between hops.  So where are the log lines for the re-routes?  It 
appears to me PF is ignoring my route-to(s), or it is ignoring the 
source and not matching, and the request is simply going out whichever 
of my two multipath default routes gets chosen at the time.




Re: Checking Routes/Gateways For Good Connection

2010-08-27 Thread Don Tek
 Well, I thought I had this issue worked out, but my pf rules aren't 
evaluating as I expected them to:


PF Rules: (rule number prepended, these are the _last_ 6 lines in my pf.conf)

39:pass out quick log on em0 from 172.16.0.1 route-to (em0 192.168.0.1)
40:pass out quick log on em1 from 172.16.1.1 route-to (em1 10.10.0.1)
41:pass out log on em0
42:pass out log on em1
43:pass out log on em0 from em1 route-to (em1 10.10.0.1)
44:pass out log on em1 from em0 route-to (em0 192.168.0.1)



Tests:

$ traceroute -s 172.16.0.1 -n google.com



Tcpdump pflog0 output:

Aug 27 15:35:16.418090 rule 42/(match) pass out on em1: 172.16.0.1.34561>  
74.125.45.106.33438: udp 12
Aug 27 15:50:01.658596 rule 41/(match) pass out on em0: 172.16.0.1.63615>  
74.125.45.103.33444: udp 12



Why are these packets not being caught by rule 39 and always going out the em0 
gateway?



Checking Routes/Gateways For Good Connection

2010-08-25 Thread Don Tek
 I've recently implemented a firewall with two internet connections 
using multipath routing and round-robin outbound load balancing.


I am looking for a solution from the shell to detect failure of these 
two internet gateways so I can force routing and pf changes from a script.


I need something more robust than simply checking to see if the 
interface is up or down.


I have managed a solution using traceroute that allows me to accomplish 
half of my goal.  I can detect a failure and "down" that route, however, 
once I delete the default route from the routing table for the failed 
connection, I can no longer test it with traceroute.  This is because it 
doesn't appear to me that OpenBSD's traceroute allows forcing an 
interface to work on.


I am looking for better solutions from some of you more experienced 
users.  Any suggestions are welcome.


don..



Re: firewall rukes for OPC?

2010-07-22 Thread Don Tek
 You are likely dealing with an OPC Client that uses DCOM on TCP 135.  
Not sure if you want to open this to the public though.


On 7/22/2010 1:58 PM, stan wrote:

I need to allow an OPC client and server to connect through one of my
firewalls.

Can anyone tell me what ports I need to open up for this to work?