Frontend loses network access

[John Price]

Hi all:

I apologize for not being active here, but so far I've been unable to get rocks to work reliably on my system.  At my school, there is a strong preference to *not* have "real" static IP addresses, but rather to set up their DHCP server to always give me the same address (based on the MAC address of my network card).  Theoretically, I suppose this "should" have the same effect as having an actual static IP address, but I still see the same problem.

Before I realized what our network situation was here, I gave the CentOS installer my "static" IP address, and found that I was unable to find any rolls.  Thinking (correctly) that I was not able to access the network, I would boot the computer with a rescue CD, and have it pick up an IP address via DHCP.  Once that happened, I was then able to reboot with the USB stick and install rocks (again telling the installer that I had an actual static IP address).  Some time later (apparently) I lost the lease on the IP address, and was no longer able to see the network.

Once I realized that this was the cause, I tried to install rocks again, this time telling the installer to use DHCP for my public network.  The installation went fine, but a short time later, the same thing happened.  I could no longer see the network from my frontend, and I could not log into it from the outside.

So, my questions:

1. "Should" this work, setting up networking via DHCP, as long as my institution does in fact give me the same address all the time?

2. Assuming the answer to (1) is "yes", where should I look in my log files to find hints to the underlying problem I'm seeing?

Thanks,
John

[nadya williams]

John,

it looks like your example already “proved” that you can not reliably get the same DHCP-assigned address.

Rocks installation always depended on a static public IP and i don’t believe this have changed for 7. 

To answer your questions:

(1) may be, but any hiccup with DHCP renders your cluster unusable. 

(2)  for after install, look in 

/tmp for a few post install logs or debug info.

  /root for anaconda and installer logs and info

/var/log for other services and messages

nadya

--
You received this message because you are subscribed to the Google Groups "rocks7-beta" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rocks7-beta...@googlegroups.com.
To post to this group, send email to rocks...@googlegroups.com.
Visit this group at https://groups.google.com/group/rocks7-beta.
To view this discussion on the web visit https://groups.google.com/d/msgid/rocks7-beta/32da5633-a65b-41d5-8b05-840267a5ce7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nadya Williams                 University of California, San Diego

na...@sdsc.edu             9500 Gilman Dr. MC 0444

+1 858 534 1820 (ofc)      La Jolla, CA 92093-0444

+1 858 822 1619 (fax)      USA

[Philip Papadopoulos]

On Mon, Nov 6, 2017 at 6:31 PM, nadya williams <na...@sdsc.edu> wrote:

John,

it looks like your example already “proved” that you can not reliably get the same DHCP-assigned address.

Rocks installation always depended on a static public IP and i don’t believe this have changed for 7.

Not changed. a cluster is a server and servers don't change their IPs (at least not generally).  

When the IP address of the frontend changes, you may have to redo both firewall and  some internal routing.

There are many moving parts to a cluster with a scheduler and subordinate nodes.  Changing the public IP address is

"doable" (not supported and I'm not going to take time to support it).  Changing the DNS name of the frontend is a much 

deeper change, and generally requires more surgery.

-P

 

To answer your questions:

(1) may be, but any hiccup with DHCP renders your cluster unusable. 

(2)  for after install, look in 

/tmp for a few post install logs or debug info.

  /root for anaconda and installer logs and info

/var/log for other services and messages

nadya

On Nov 6, 2017, at 4:26 PM, John Price <jpr...@csudh.edu> wrote:

Hi all:

I apologize for not being active here, but so far I've been unable to get rocks to work reliably on my system.  At my school, there is a strong preference to *not* have "real" static IP addresses, but rather to set up their DHCP server to always give me the same address (based on the MAC address of my network card).  Theoretically, I suppose this "should" have the same effect as having an actual static IP address, but I still see the same problem.

Before I realized what our network situation was here, I gave the CentOS installer my "static" IP address, and found that I was unable to find any rolls.  Thinking (correctly) that I was not able to access the network, I would boot the computer with a rescue CD, and have it pick up an IP address via DHCP.  Once that happened, I was then able to reboot with the USB stick and install rocks (again telling the installer that I had an actual static IP address).  Some time later (apparently) I lost the lease on the IP address, and was no longer able to see the network.

Once I realized that this was the cause, I tried to install rocks again, this time telling the installer to use DHCP for my public network.  The installation went fine, but a short time later, the same thing happened.  I could no longer see the network from my frontend, and I could not log into it from the outside.

So, my questions:

1. "Should" this work, setting up networking via DHCP, as long as my institution does in fact give me the same address all the time?

2. Assuming the answer to (1) is "yes", where should I look in my log files to find hints to the underlying problem I'm seeing?

Thanks,
John

--
You received this message because you are subscribed to the Google Groups "rocks7-beta" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rocks7-beta+unsubscribe@googlegroups.com.

To post to this group, send email to rocks...@googlegroups.com.
Visit this group at https://groups.google.com/group/rocks7-beta.
To view this discussion on the web visit https://groups.google.com/d/msgid/rocks7-beta/32da5633-a65b-41d5-8b05-840267a5ce7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nadya Williams                 University of California, San Diego

na...@sdsc.edu             9500 Gilman Dr. MC 0444

+1 858 534 1820 (ofc)      La Jolla, CA 92093-0444

+1 858 822 1619 (fax)      USA

--
You received this message because you are subscribed to the Google Groups "rocks7-beta" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rocks7-beta+unsubscribe@googlegroups.com.

To post to this group, send email to rocks...@googlegroups.com.
Visit this group at https://groups.google.com/group/rocks7-beta.

To view this discussion on the web visit https://groups.google.com/d/msgid/rocks7-beta/34E7F686-98BB-41F6-A2CF-E4F4608C07A4%40sdsc.edu.

For more options, visit https://groups.google.com/d/optout.

--

Philip Papadopoulos, Ph.D

ppapad...@ucsd.edu

(858) 822-3628

[John Price]

Thanks to both Nadya and Philip. I will try to beat our IT people into
submission to get a real "static" IP address. My main cluster has one,
so there "shouldn't" be any reason why my test cluster can't have one
too.

John

> > +unsub...@googlegroups.com.

> > To post to this group, send email to
> > rocks...@googlegroups.com.
> > Visit this group at
> > https://groups.google.com/group/rocks7-beta.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/rocks7-beta/32da5633-a65b-41d5-8b05-840267a5ce7a%40googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
>
> Nadya Williams University of California, San
> Diego
> na...@sdsc.edu 9500 Gilman Dr. MC 0444
> +1 858 534 1820 (ofc) La Jolla, CA 92093-0444
> +1 858 822 1619 (fax) USA
>
>
>
>
>
>
>
--

John W. Price
Professor and Chair, CSUDH Department of Physics
Coordinator, Science, Mathematics, and Technology Program
Director, Office of Undergraduate Research, Scholarship, and Creative
Activity
310-243-3403

[Philip Papadopoulos]

If they give you a persistent IP address, you can install with a static IP and then on first boot change the config

of that interface to be DHCP so that their servers are happy with DHCP renewals and don't give away your IP address.

It's not that DHCP is a problem, per se, it's changing the IP address and (possibly) the DNS name.

-P

[John Price]

Sorry it's taken me so long to get back on this, but it's been problematic isolating the cause of my problem.  I'm still not sure I'm there, but...

I managed to get my frontend installed using DHCP.  All seemed to go fine.  I was able to get out to the rest of the world from my new box, and I was able to get into it from the outside.  All seemed well.

Then, after a week or so (could have been earlier; I was distracted...), I lost network access again.  It seems that my network card decided to claim its IP address, instead of using DHCP -- even though I specified DHCP during the installation.  I reset it to DHCP, and am now using that computer to send this message (i.e., it's connected now).

Any ideas on how something like this could happen, or where in the log files I should look to diagnose the problem?

Thanks,
John

[John Price]

Hi all:

After fixing a bunch of (mostly) self-inflicted wounds, I now have a functioning, if minimal cluster, with the frontend and one compute node.  I still have the DHCP issue connecting the frontend to the world, using the RC0 kernel.  Would it be worth reinstalling with the RC1 kernel to verify that this problem still exists?

Recapping: Rocks 7 is installed on the frontend using DHCP to set up the public network interface.  This is set up by my IT people to always give me the same IP address, based upon the MAC address of the frontend.  After installation, I noticed at some point (this needs clarification on my part) that the frontend lost its connection to the network.  Upon further investigation, I found that network interface is not using DHCP, but instead sets the assigned IP address manually.  Resetting the network interface to use DHCP seems to have fixed the problem, and all "appears" to work as expected.

[Philip Papadopoulos]

To set your frontend's public interface to dhcp

supposing the interface is enps0f0

# rocks set host interface options frontend enps0f0 dhcp

# rocks sync host network frontend

You should be able to see the appropriate changes in /etc/sysconfig/network-scripts/ifcfg-enps0f0

(replace enps0f0 with the name of your frontend's public interface)

-P

--

You received this message because you are subscribed to the Google Groups "rocks7-beta" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rocks7-beta+unsubscribe@googlegroups.com.

To post to this group, send email to rocks...@googlegroups.com.
Visit this group at https://groups.google.com/group/rocks7-beta.

To view this discussion on the web visit https://groups.google.com/d/msgid/rocks7-beta/1a74462f-4e2f-4d4e-8d56-03c86ee7058a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[John W. Price]

Hi Philip:

That’s effectively what I did.  Instead of the “rocks” commands, I used the Settings GUI, and did the equivalent task (although I don’t think that includes the “rocks sync host” command).  My concern is that, even though I set it to DHCP at *install* time, it was set to manual *after* the installation was complete.

Note that this is not yet completely diagnosed, so no action should be taken at this time.  I may even have the gross features of this effect incorrect, to the extent that it’s completely operator error on my part, although I believe that is not the case.  When I install the RC1 kernel (probably next week), I’ll record what I do very carefully, and observe the state of the network interface immediately after installation.  I’ll report back either way.

John

-- 

John W. Price

Professor and Chair, CSUDH Department of Physics

Coordinator, Science, Mathematics, and Technology Program

Director, Office of Undergraduate Research, Scholarship, and Creative Activity

310-243-3403