Re: Netserver no start when internet down

Jeff,

I suppose if everything is on the SAN and the SAN is down, it doesn't
matter that you can't look up internal resources; might as well let
everybody surf the net.

But for most companies, allowing access to internal resources is more
important than providing access to external resources.

Personally, I'd consider having a stand-a-lone server providing backup
AD/DNS services.

Charles

On Fri, May 15, 2015 at 10:18 AM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
wrote:

> Charles,
>
> "Those DNS servers are the only ones that should be contacting internet
> based
> DNS servers."
>
> Why?  We're a small company.  We have 2 Windows servers, both virtual,
> serving DNS.  Both on the one and only SAN we have.  Why not have an
> additional DNS server "out there" in case the SAN has an issue?
>
> Just curious.
>
>
> On Fri, May 15, 2015 at 9:00 AM, Charles Wilt <charles.wilt@xxxxxxxxx>
> wrote:
>
> > Once it's started, it doesn't matter so much.
> >
> > IMO, you should have at least primary and backup internal DNS servers.
> > Those DNS servers are the only ones that should be contacting internet
> > based DNS servers.
> >
> > Charles
> >
> >
> > On Fri, May 15, 2015 at 8:47 AM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
> > wrote:
> >
> > > It all makes sense to me.  But I'm kind of amazed we never noticed it
> > > during other internet outages.  We very seldom experience an outage but
> > > over a 10+ year period you'd think we would have noticed it before.
> > >
> > >
> > > On Fri, May 15, 2015 at 7:18 AM, Jim Oberholtzer <
> > > midrangel@xxxxxxxxxxxxxxxxx> wrote:
> > >
> > > > I agree with putting the system name/IP entry in the local host
> table,
> > > > that's critical for several things not just the Netserver.  There is
> a
> > > > reasonable alternative.  IBM i has a DNS server built in to it.  Most
> > > folks
> > > > chose not to use it but it's there.   You could simply configure that
> > as
> > > a
> > > > backup to the main DNS and now your back to only one place to change
> > it.
> > > > You would only put the addresses/domains that are internal to your
> shop
> > > in
> > > > it but then as long as either the M$ DNS is running  --or-- your IBM
> i
> > > > server is running you'll get DNS resolution.
> > > >
> > > > Now some will immediately spring up and claim that auditors will
> never
> > > > accept an IBM i running DNS for whatever reasons Microsoft has
> managed
> > to
> > > > convince them about using anything but AD as your DNS server, but
> > that's
> > > > really all FUD.  If you keep up with the security PTFs and the other
> > > > updates
> > > > IBM puts out, there is really no issue with it.
> > > >
> > > > --
> > > > Jim Oberholtzer
> > > > Chief Technical Architect
> > > > Agile Technology Architects
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf
> Of
> > > > Scott
> > > > Klement
> > > > Sent: Thursday, May 14, 2015 11:23 PM
> > > > To: Midrange Systems Technical Discussion
> > > > Subject: Re: Netserver no start when internet down
> > > >
> > > >
> > > > Jeff,
> > > >
> > > > NetServer needs to know it's host and IP address.  The problem with
> IP
> > > > address is that the system can have many of them, so how does it know
> > > which
> > > > one is the "main" IP address?
> > > >
> > > > So what it does is take your hostname (QDILGARD in your case) and try
> > to
> > > > perform a DNS lookup to get the IP address.  It will then use that as
> > the
> > > > main IP address for NetServer.
> > > >
> > > > Apparently your DNS was set up to contact Internet DNS servers -- so
> > the
> > > > lookup would fail (or time out) before getting a result for QDILGARD.
> > > > Therefore it could not start the NetServer.
> > > >
> > > > Putting QDILGARD in the host table means that it'll always be able to
> > > find
> > > > it's own IP address, even if the network is down.  So this is
> > considered
> > > a
> > > > "best practice" to always have the IP address that's connected to the
> > > > system
> > > > name be in the host table.  Granted, this does mean that there's one
> > more
> > > > place to change it if the IP address changes...  but as long as this
> > (and
> > > > the DNS server) are the only places, that shouldn't be too
> > cumbersome.  A
> > > > lot better than being down when the Internet is offline!
> > > >
> > > > -SK
> > > >
> > > >
> > > > On 5/14/2015 1:47 PM, Jeff Crosby wrote:
> > > > > I learned something this morning and thought I would pass it along
> in
> > > > > case it helps someone else.
> > > > >
> > > > > The day started with the internet being down.  In doing backup
> checks
> > > > > I noticed the BRMS recovery reports had not been copied to a
> Windows
> > > > > file server within the domain.  Reason is because Netserver was not
> > > > started.
> > > > > Tried to reset and start Netserver and got this in QSYSOPR (I
> > stripped
> > > > > out some portions):
> > > > >
> > > > > Message ID . . . . . . :   CPIB683
> > > > >
> > > > > Date sent  . . . . . . :   05/14/15      Time sent  . . . . . . :
> > > > > 07:16:51
> > > > >
> > > > >
> > > > > Message . . . . :   IBM i Support for Windows Network Neighborhood
> > > (IBM i
> > > > >
> > > > >    NetServer) was unable to start.
> > > > >
> > > > >
> > > > >
> > > > > Cause . . . . . :   The required IBM i NetServer job QZLSSERVER was
> > > > unable
> > > > > to
> > > > >    start because of reason code 13.  See the following reason codes
> > > > > and their
> > > > >    meanings:
> > > > >
> > > > >      13 - The retrieved host IP address of 6.0.0.7 is invalid.
> > > > >
> > > > > Recovery  . . . :   Complete recovery for the specified reason
> code.
> > > > >    13 - Correct the name configured for IBM i NetServer which
> > > > > conflicts with an existing name on the network, and try the request
> > > > again.
> > > > >
> > > > > The Netserver name has not changed since day one so I opened a PMR
> > (by
> > > > > phone since no internet either!).  No idea what the 6.0.0.7 IP
> > address
> > > is
> > > > .
> > > > > . .
> > > > >
> > > > > After the internet came back up just for fun I tried starting
> > > > > Netserver again and it worked.  Huh?  What does the internet have
> to
> > do
> > > > with it?
> > > > >
> > > > > Rochester called in response to the PMR and she said she could fix
> > > that.
> > > > > In CHGTCPDMN we have 3 DNS servers listed, 1 internal Windows and 2
> > > > > Comcast.  The 2 external have something to do with it.  So she had
> me
> > > > > add the Netserver name "QDILGARD" to the host table entries on the
> > IBM
> > > > > i so it would find the IP address for the i there.  With or without
> > > > > internet.  She was aware of this behavior but could not answer why.
> > > > > She was curious herself, said she would ask the developer when he
> > > > > arrived, and report back to me via the PMR.
> > > > >
> > > > > I waited until now hoping the PMR would have something of an
> > > > > explanation, but it still does not.  If I get something I will pass
> > it
> > > > along.
> > > > >
> > > > >
> > > >
> > > > --
> > > > 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.
> > > >
> > > >
> > >
> > >
> > > --
> > > Jeff Crosby
> > > VP Information Systems
> > > UniPro FoodService/Dilgard
> > > P.O. Box 13369
> > > Ft. Wayne, IN 46868-3369
> > > 260-422-7531
> > > www.dilgardfoods.com
> > >
> > > The opinions expressed are my own and not necessarily the opinion of my
> > > company.  Unless I say so.
> > > --
> > > 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.
> >
> >
>
>
> --
> Jeff Crosby
> VP Information Systems
> UniPro FoodService/Dilgard
> P.O. Box 13369
> Ft. Wayne, IN 46868-3369
> 260-422-7531
> www.dilgardfoods.com
>
> The opinions expressed are my own and not necessarily the opinion of my
> company.  Unless I say so.
> --
> 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.
>
>