× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Rob,

You can fix the DNS single point of failure by making yourself the authoritative DNS provider with redundant DNS servers in conjunction with redundant load balancers, every load balancer has built in functionality to automatically know if hosts are up or down and route accordingly. Perhaps you have an ancient device that can't be clustered, anything on today's market can get you by this hurdle.

Matt

-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
Sent: Tuesday, September 03, 2013 12:27 PM
To: Midrange Systems Technical Discussion
Subject: RE: iSeries public WEB access, PCI security issues

Often the web suggestions I get try to throw a single point of failure in there somewhere along the line.
let's see, we'll use
- replicated DB2 databases
- clustered WAS based application servers
- multiple DNS servers
however I cannot use round robin DNS spraying because it could route me to a WAS or DB2 server that is down. For example, just because I can PING MYWASSERVER doesn't mean WAS is up, or even HTTP is up. So I get an intelligent server that checks comm over a certain port. And route everything through that. So now does it know that MYWASSERVER is xxx.xxx.xxx.xxx but it now knows that comm is working on port (9231 for
example) and we know that port is used by our WAS application. Only to find out that such appliance cannot be clustered and is now our new single point of failure. And my boss says run it on IBM i, that's robust. Well, yes it is. However we also drop that for an entire weekend once a quarter to upgrade the OS or put PTF's on it or upgrade hardware or move it from one location to another or...
So you end up doing stuff like changing DNS manually before you drop the one server.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Matt Olson <Matt.Olson@xxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 09/03/2013 01:17 PM
Subject: RE: iSeries public WEB access, PCI security issues
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Your raid controller just failed on your single i box that runs
EVERYTHING. Instead of just one of the web front ends failing, your whole
system just went down. Hmm. Sounds like poor infrastructure design.

Theres your rebuttal.

-----Original Message-----
From: Nathan Andelin [mailto:nandelin@xxxxxxxxx]
Sent: Tuesday, September 03, 2013 12:01 PM
To: Midrange Systems Technical Discussion
Subject: Re: iSeries public WEB access, PCI security issues

From: Matt Olson
PCI is not focused on intel servers.

What about:

"2.2.1 Implement only one primary function per server to prevent functions
that require different security levels from co-existing on the same
server. (For example, web servers, database servers, and DNS should be
implemented on separate servers.)"

While there's no mention of Intel or Windows, PCI foments the idea that
distributed application architecture is more secure, when in fact it is
normally LESS secure because of the difficulty of administering multiple
types of security, the disparity between security mechanisms, and the
complexity of managing multiple environments.

Intel servers can perfectly house hundreds/thousands of applications
on a single box, just like the i.

You say Intel, but you must mean Windows or Linux wherein complex
workloads tend to destabilize those environments.

However most people chose not to as it's a single point of failure.


That seems co support my assertion that complex workloads tend to cause
Windows and Linux environments to fail. I'd be interested in hearing a
rebuttal.

-Nathan




-----Original Message-----
From: DrFranken [mailto:midrange@xxxxxxxxxxxx]
Sent: Thursday, August 29, 2013 12:54 PM
To: Midrange Systems Technical Discussion
Subject: Re: iSeries public WEB access, PCI security issues

I agree, FUD.

I seem to recall that PCI says you cannot store Credit Card numbers for
more than 3 days period and even if you do they must be encrypted. Most of
the folks I work with that do Credit Card transactions store only the last
four digits for any length of time.

And while I won't list them I know of MANY companies who's IBM i servers
are connected directly to the internet with web and database on the same
server. PCI seems to be interpreted to focus on Intel based systems where
proliferation of servers is needed to support staff size and Microsoft and
Oracle revenue streams.


- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 8/28/2013 10:58 AM, rob@xxxxxxxxx wrote:

I question whether someone says PCI rules don't allow this as FUD
rather than fact.

You're probably not interested in how we serve up our public
accessible parts of our website that require login's for customers and
suppliers that are Domino based...


Rob Berendt

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.